Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Single Ecore domain model, two conflicting serializations, now what?
Single Ecore domain model, two conflicting serializations, now what? [message #1748290] Mon, 21 November 2016 20:23 Go to next message
Daniel Ford is currently offline Daniel FordFriend
Messages: 148
Registered: July 2009
Location: New York
Senior Member
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 #1748292 is a reply to message #1748290] Mon, 21 November 2016 20:26 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
This looks like a usecase for http://xtextcasts.org/episodes/18-model-optimization

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Single Ecore domain model, two conflicting serializations, now what? [message #1748441 is a reply to message #1748290] Wed, 23 November 2016 08:55 Go to previous messageGo to next message
Jan Koehnlein is currently offline Jan KoehnleinFriend
Messages: 760
Registered: July 2009
Location: Hamburg
Senior Member
It may be a bit hard to derive that from the post that Christian referred to, so I try to summarize the general idea:

Do not use your Ecore model as the model for the parse tree but a relexed one. Then derive an instance of your Ecore model from that after the parser has done its work. This way you can decouple the actual AST model from the model you actually want to process with maximum flexibility. The hook for this is the IDerivedStateComputer/...Resource/...ResourceDescription.

The backside of it is that you cannot make changes to the derived model and write them back unless you keep traces to the original, but this seems to be no problem as you already have two(!) ways of serializing it back.


---
Get professional support from the Xtext committers at www.typefox.io
Re: Single Ecore domain model, two conflicting serializations, now what? [message #1748491 is a reply to message #1748441] Wed, 23 November 2016 15:12 Go to previous messageGo to next message
Daniel Ford is currently offline Daniel FordFriend
Messages: 148
Registered: July 2009
Location: New York
Senior Member
Thanks for the additional input. I'm busy working on a plan that I think will work and will post back with an explanation of what I did. Basically, I plan to modify the DSL definition to use a different attribute to collect the key/value pairs, this should create a subclass in the generated model. Then I plan to modify that model in post processing to make the attribute "derived" and then add my own code that will "intercept" use of that attribute and do the appropriate processing to translate between the representation used in the domain model Ecore. I think it will work.

Dan
Re: Single Ecore domain model, two conflicting serializations, now what? [message #1749348 is a reply to message #1748491] Mon, 05 December 2016 18:17 Go to previous messageGo to next message
Daniel Ford is currently offline Daniel FordFriend
Messages: 148
Registered: July 2009
Location: New York
Senior Member
I had to "push the stack" and complete the JSON implementation before I could tackle refactoring the processing of the DSL to support overloading the use of a single key value.

As I started to make progress, using the technique suggested above, I discovered that post processing of the inferred model is not supported in Xtext 2.10, which is the version I'm using.
See: http://stackoverflow.com/questions/34381807/xtext-customize-inferred-genmodel
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=483209

Refactoring to use a back level version of Xtext that supports such isn't really an option for me. I looked for documentation on this issue, a migration guide would have been great, but I didn't find anything.

Any suggestions on what I can do next?

Thanks
Dan
Re: Single Ecore domain model, two conflicting serializations, now what? [message #1749356 is a reply to message #1749348] Mon, 05 December 2016 19:27 Go to previous message
Jan Koehnlein is currently offline Jan KoehnleinFriend
Messages: 760
Registered: July 2009
Location: Hamburg
Senior Member
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.


---
Get professional support from the Xtext committers at www.typefox.io
Previous Topic:Enumeration Element Cross Reference
Next Topic:Implicit static extensions
Goto Forum:
  


Current Time: Tue Apr 16 19:08:28 GMT 2024

Powered by FUDForum. Page generated in 1.61700 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top