Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [XCore] / [EMF] Derived Attribute notifier definition/generation from model(Looking for an elegant way to extend generated code for DerivedAttributeAdapter )
[XCore] / [EMF] Derived Attribute notifier definition/generation from model [message #1780106] Wed, 17 January 2018 12:36 Go to next message
Nikola Veber is currently offline Nikola VeberFriend
Messages: 29
Registered: December 2017
Junior 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!
Re: [XCore] / [EMF] Derived Attribute notifier definition/generation from model [message #1780122 is a reply to message #1780106] Wed, 17 January 2018 16:02 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7060
Registered: July 2009
Senior Member

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.


Ed Willink
Re: [XCore] / [EMF] Derived Attribute notifier definition/generation from model [message #1780147 is a reply to message #1780122] Thu, 18 January 2018 07:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 31780
Registered: July 2009
Senior Member
The IncQuery stuff may be interesting for you 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:
Re: [XCore] / [EMF] Derived Attribute notifier definition/generation from model [message #1780223 is a reply to message #1780147] Thu, 18 January 2018 18:02 Go to previous message
Nikola Veber is currently offline Nikola VeberFriend
Messages: 29
Registered: December 2017
Junior 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:).

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

Current Time: Sun Mar 07 23:59:19 GMT 2021

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

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

Back to the top