Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
VIATRA/Query/DeveloperDocumentation/Features/Xcore
Contents
Xcore integration
Xcore meets IncQuery
Live abstractions powered by incremental graph search
IncQuery Viewers can be used to create live abstractions for your models with a few lines of code. Live abstractions allow your users to manage complex modeling scenarios by providing live updating views that focus on interesting parts of the model.
IncQuery Viewers supports the JFace Viewer Framework as well as the Zest Graph Visualization Framework (available as open source), as well as the powerful yFiles Graph Visualization Toolkit from yWorks (available as a commercial add-on from IncQueryLabs Ltd.).
Query-based derived features with automatic notification support
In co-operation with Ed Merks, the EMF-IncQuery team have developed a deep integration between live graph search and Xcore, the Xtext-based textual syntax for Ecore metamodeling. With this feature, you can write live graph queries with EMF-IncQuery and integrate them transparently into your DSL in the form of derived features that support automatic notifications. As we will show, these query-based derived features can significantly boost the expressive power of your metamodels, help you get rid of a lot of cruft and improve the scalability of your modeling tool.
Xcore
- Extended textual syntax for Ecore-based metamodelin built on Xtext
- Fully fledged programming language
- To specify structure + behavior (operations, datatype conversion logic)
- http://wiki.eclipse.org/Xcore
Xbase
- Xtext-based programming language
- Compiles to Java
- Java type system
- Supports advanced constructs (closures, type reference, operator overloading, ...)
- http://wiki.eclipse.org/Xbase
Aim of the project
Viewing the scope of the EMF-IncQuery project an idea may immediately arise; it would be really nice to use the powerful pattern language of EMF-IncQuery to define derived features in your Xcore metamodel. This project aims to support exactly this functionality, that is, beyond the standard Xcore way to define derived features (basically with Xbase expressions), it is now possible to refer to pattern definitions in the Xcore files. One can specify which pattern should serve as the underlying logic for the evaluation of the given derived feature in runtime.
Another key benefit of using EMF-IncQuery to define derived features is that these features are well-behaving features [6] as opposed to most of the standard derived features in EMF. A derived feature is well-behaving if proper change notifications are sent upon modifications of the underlying model elements. However, this does not hold for regular derived features which usually have no field (meaning that they do not store the current value) therefore they are unable to send proper notifications (e.g. SET oldValud to newValue).
The integration was developed as seamlessly as possible; all the original Xcore semantics and toolset are still available, however, the IncQuery Xcore editor now supports the definition of the above mentioned features with additional features like validation, proposal providers, etc.
Editing Dynamic Instance Model from the Model Editors
Dynamic instance models must be edited with the Reflective Ecore Model Editor for IncQuery-Xcore, because this editor initializes the QuerySpecificationRegistry before the model can be edited. Without this step the derived features will not work and all setting delegates return an empty result as the underlying query specifications cannot be found.
An other problem with the standard Sample Reflective Editor is that it loads an unnecessarily big amount of TypeResource instances into the ResourceSet. The problem gets even worse if you want to edit some references in the Properties View. After clicking into the View you need to wait 1-2 mins until all additional (and unnecessary) TypeResources are loaded into the ResourceSet (this is because of the poor implementation of the underlying internal logic). This would also affect the performance of the EMF-IncQuery engine because a huge ResourceSet needs to be traversed. In order to avoid this problem the Reflective Ecore Model Editor for IncQuery-Xcore is optimized to avoid this excessive loading. To achieve even better performance, the scope of pattern matching is restricted to Resource scope for the Xcoreiq ResourceSets and the EMF-IncQuery Base Index is working in Dynamic EMF Mode.
See also: http://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/IncQueryXcore