| Single Ecore domain model, two conflicting serializations, now what? [message #1748290] |
Mon, 21 November 2016 15:23  |
Eclipse User |
|
|
|
I have an Ecore model that represents a particular domain model. I also have two different "standard" serializations of the model developed by others (i.e., I can't change them). One serialization is essentially JSON, while the other is a DSL.
My problem is that they have different conflicting serializations of sets of key/value pairs that I'm having difficulty resolving. The issue is that a key may appear in multiple key/value pairs, and the two different serializations have different ways of representing that.
The first serialization definition is essentially JSON and uses a JSON array for multiple values:
e.g., "key" : [ 2, 3 ]
while, the second is a DSL that just repeats the key value:
e.g.,
"key":2, "key":3
Of course, the pairs can occur in any order, and be combined with other pairs with different keys and values.
I know how to handle/represent/parse the JSON case, but being able to do the same for the DSL given the same common underlying Ecore model is not clear to me.
In the first case (i.e., JSON), I can have something in the common Ecore model that would represent a mapping between the key and a list of its values. in the second case (DSL), I'm not sure how to recognize multiple uses of the same key, and then get the collection of its values into the same list in an instance of the Ecore model.
One approach I've wondered about is to use some kind of ability to be notified when the parser has recognized a collection of key/values, and have it call out to my custom code to do a bit of aggregation of the keys and their values in the AST under construction. Something similar would need to happen in the reverse for serialization to the DSL.
Thoughts?
Dan
|
|
|
|
|
|
|
| Re: Single Ecore domain model, two conflicting serializations, now what? [message #1749356 is a reply to message #1749348] |
Mon, 05 December 2016 14:27  |
| Eclipse User |
|
|
|
Yes, the ecore mode post-processing is no longer supported. But that was used to change the ecore model that Xtext derives from the grammar when you run the Xtext generator. This model describes the classes of the elements in the AST. The post-porcessing hook can be completely replaced by using an imported ecore model that has been written by hand (or adapted from a prior generated version). Please refer to the documentation for details.
I still think your main task is about changing the instances of these models, i.e. the ones that the parser creates when it parses a DSL file, the nodes of the AST. This can be done by the derived state classes I referred to earlier. The blogpost from xtextcasts uses both, but I think you just need the latter.
|
|
|
Powered by
FUDForum. Page generated in 0.03810 seconds
Home