Eclipse Community Forums: EMF » [XCore] / [EMF] Derived Attribute notifier definition/generation from model

Home » Modeling » EMF » [XCore] / [EMF] Derived Attribute notifier definition/generation from model(Looking for an elegant way to extend generated code for DerivedAttributeAdapter )

Show: Today's Messages :: Show Polls :: Message Navigator

[XCore] / [EMF] Derived Attribute notifier definition/generation from model [message #1780106]

Wed, 17 January 2018 12:36

Nikola Veber

Messages: 31
Registered: December 2017

Member

Hi everyone,

first, let me thank you for your work, on Eclipse Project and in this forum!

I have been looking around for the solution for notifications on derived fields once the input has changed.
After finding multiple questions and answers here on the forum, I implmented the DerivedAttributeAdapter as described in this recipe with success.

I am not sure whether I understood correctly that this is still the proposed way to do it. (slight Timeline-keeping problem on my side and KUDOs for the long-time support)

(assuming I did)
Is there a way to define this semantic dependency in the model? I am happy with the workflow of defining the derivation code in XCore, so this adaptation of the generated model code seems misplaced.

Maybe there is a way to extend the tooling for this feature, I imagine by something like "notifiedBy [list of features]" keyword, which would in turn generate the constructor with DerivedAttributeAdapter definition?

I remember reading a feature thread about this implementation where OCL was mentioned. Would OCL be an alternative to XCore?

Best regards!
Nikola

Report message to a moderator

Re: [XCore] / [EMF] Derived Attribute notifier definition/generation from model [message #1780122 is a reply to message #1780106]

Wed, 17 January 2018 16:02

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

OCLinEcore is an alternative to Xcore. It has advantages in that OCL is an OMG-specified abstract modeling language. It has disadvantages in not benefiting from a larger development team and the much stronger Java integration that Xbase provides. OCL is side-effect free whereas Java and Xbase are not.

If you are really interested in modeled automation, you may be more interested in model transformation. If your transformation is realized as an auto-generated incremental transformation, then the auto-generated incremental functionality is exactly your derived features analysis. The underlying support for OCL-in-Ecore is currently hand coded. It needs an incrementally updating mapping between the Ecore model representation used by the Sample Ecore Model Editor and the normalized Pivot representation used by the OCL validation. For the OCLinEcore editor this needs to be bidirectional. This bidirectional incremental transformation is now my current use case in pushing the auto-generated Java implementations of QVTr through for the 1.0 release in June. Very cutting edge, so probably just for future interest.

Notifiers are a good approach for manual code since it allows notifier and listener to be flexible and largely independent, but it tends to incur costs as numerous listeners receive numerous irrelevant notifications. In contrast autogenerated code can connect known notifiers to known listeners directly and accurately. You may have noticed how in the Sample Ecore Editor, many of the higher level titles fail to refresh when lower level names change; this is inevitable since it is difficult and unprofitable for a manual coder to capture all the dependencies that affect text rendering. In contrast you may notice that the Xtext outline is much better at the expense of non-trivial execution time for full recalculations. An autogenerated functionality can be accurate and fast, although perhaps a bit bulky on code size.

Regards

Ed Willink

Report message to a moderator

Re: [XCore] / [EMF] Derived Attribute notifier definition/generation from model [message #1780147 is a reply to message #1780122]

Thu, 18 January 2018 07:25

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

The IncQuery stuff may be interesting for you https://wiki.eclipse.org/VIATRA/Integration/DeveloperDocumentation/Xcore and OCLinEcore is also a possibility as Ed W explained.

I imagine you could modify the approach in the recipe so that you define/implement a static utility method that effectively does what the recipe shows in the constructor, but guarded so that the adapter is not added if already attached and you could call that method in your derived feature's getter. I.e., essentially demand create the adapter the first time the value is fetched for that derived feature; after all, if nothing has fetched the value, nothing need be notified about a change.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [XCore] / [EMF] Derived Attribute notifier definition/generation from model [message #1780223 is a reply to message #1780147]

Thu, 18 January 2018 18:02

Nikola Veber

Messages: 31
Registered: December 2017

Member

Ed, Ed,

thank you very much for the quick responses!

I thought about Viatra/IncQuery (after seeing some video presentations) but thouht it to be an overkill in my case (not overly complex complex-data definition), as I would have only a couple of simple derived features - so I guess manually implenting Notifiers in Java would be appropriate.
Last night I came up with a very (c)rude and dirty solution: I registered a listener on the EMF Forms renderer I use for displaying the data which sets the same EObject as input to the renderer once it detects changes in the source-features of the derived one. Now I have some time to check out your proposals (a newby needs some time:).

Report message to a moderator

Previous Topic:	[XCORE] generated class files not updated
Next Topic:	References not stored in xmi file when I save the objects

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 16:07:22 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter