search

eclipse-emfcloud / emfcloud-modelserver

Modelserver component
Other
43 stars 21 forks source link

Make XMICodec better reusable #143

Open eneufeld opened 2 years ago

eneufeld commented 2 years ago

So I stumbled over the point, that whenever we use the modelserver with a new emf model, we basically need to create an own ModelServerClient subclass as well as a XMICodec subclass see: https://github.com/eclipse-emfcloud/coffee-editor/blob/glsp-update/backend/plugins/org.eclipse.emfcloud.coffee.modelserver/src/org/eclipse/emfcloud/coffee/modelserver/CoffeeModelServerClient.java#L63 and https://github.com/eclipse-emfcloud/coffee-editor/blob/7f42783e0dcf290696db75ad8e94dbac965c5114/backend/plugins/org.eclipse.emfcloud.coffee.modelserver/src/org/eclipse/emfcloud/coffee/modelserver/CoffeeCodec.java#L23

The XMICodec could be adapted to actually handle all cases where we use the default EMF serialization without problems (by using the emf model registry). The main issue right now is, that the Codec interface does not accept a format parameter in encode and decode. I thus suggest to change the Codec interface to include the format parameter, thus allowing us to have one XMICodec which can handle all EMF resources correctly. Furthermore many clients would not need to extend the MOdelServerClient anymore.

What do you think?

MichelSc commented 2 years ago

Same observation for JsonCodec V1 and V2: I want to get the calculated fields in the returned json.

Derived fields are filtered out by https://github.com/emfjson/emfjson-jackson/blob/e59f92355ec03eeb82bb2c0a2815006ee85bb353/src/main/java/org/emfjson/jackson/databind/property/EObjectPropertyMap.java#L158

So I need a new codec. For this, I must implement:

  1. a new EObjectPropertyMap (270 lines)
  2. a new EMFSerializer (120 lines)
  3. a new EFMDeserializer (120 lines)
  4. a new CodecProvider
  5. a new JsonCodec
  6. a new EMFModule

All this work just for modifying just one little condition (deep in the code indeed).