Friday, June 24, 2011

Using Xbase to Define a Generic Graphical View

While textual representations such as code are perfectly suited to process the details of an object model, a graphical view can be very helpful to display the relationships between objects.

Most graphics frameworks in the Eclipse ecosystem provide graphical editors. Usually, the semantic model is mapped to its graphical representation using a hard wired transformation, be it in code (GEF, Graphiti) or in models and a code generator (GMF, the upcoming Spray project). There are two issues here: First, as opposed to a graphical view, a graphical editor requires the mapping to be bidirectional. That constrains the transformation a lot, e.g. requires having the same structure on the graphical as on the semantic side. Second, hard wiring the mapping introduces extra compilation/generation/deployment turnarounds.

I've created a prototype of a graphical view that is configured using two textual DSLs: A mapping DSL that declaratively describes the transformation from semantic objects to graphical elements, and a styling DSL to modify the graphical representation. The graphical view interprets the mapping and the stylesheet on a given input model, giving immediate feedback on changes of these live models.

Both DSLs are implemented in Xtext 2.0 and make heavy use of the new Xbase expression language library. As Xbase uses Java's typesystem, we can refer to any POJO as an input model. Xbase's rich semantics allow comfortably navigating the models references, and its interpreter can be customized easily to fit our needs. The graphics are implemented using plain GEF and Zest layouts.

The following screencast gives you a short demo. (Sorry for the poor video quality, it gets better if you got to full screen mode)


Holger Schill said...

Really impressive stuff. A good way to have an overview on the relations between modelelements without big effort.

Siamak Haschemi said...

Impressive stuff. Will this be open sourced?

Florian Pirchner said...

A really great job!
I am excited...

Markus Voelter said...


Ed Merks said...

That's way cool!

Unknown said...


would this approach be able to cope with layout positioning, e.g. no auto-layout.


Unknown said...

Nodes can be resized and repositioned manually, as well as edge bendpoints.

Hallvard Trætteberg said...

What is required to make the simplest editor out of this:
- add instance, i.e. draw box and say what EClass it should represent
- add EReference, i.e. draw line between two nodes and decide (if needed) which reference to populate
- edit labels
I don't mind regenerating the graphics for each action, but the layout should be fairly stable.

Unknown said...

@Hallvard Not sure whether you mean turning the view into a model editor or implementing a graphical editor to populate the map and style models.

The former would break the idea of having a unidirectional mapping from semantic to graphical elements, which is one of the sweet spots of my approach. Not only would it put constraints of the transformation, e.g. enforce similar structure of semantic model and graphical representation, but also introduce synchronization and concurrency isues with other editors. This is where many graphical frameworks get horribly complex.

The latter is what I'd call a prototype-based editor. It seems to be a logical next step to improve the user experience and is one main rationale of having interpreted models. The tricky thing will be to find a good trade-off between a simple-to-use, uncluttered UI and the unlimited expressiveness of the Xbase expressions.

Hallvard Trætteberg said...

I meant the former, a "view" with simple editing features. I agree that you target a sweet spot. I was wondering if there is an even sweeter spot nearby. Some level of editing can be introduced without the mentioned complexity, e.g. you can regenerate the graphics after each command instead of incrementally sync'ing view and model.

It's easy to implement a view that attaches to the active editor implementing IEditingDomainProvider. This gives the possibility of 1) executing commands on the editor's command stack and 2) using the adapter factory for creating the commands. You may also be able to pick up property editing stuff using the editor's getAdapter method, to utilize existing logic.

Markus Breitinger said...

Is it possible to get your source code? It would be a great starting point for one of my projects.

Anonymous said...

I am a informatics student at "CAU Kiel" and work at a similar project.
It would be nice to have a look at your created code.
Is there a possibility to get it?
Is it opensource code?

Unknown said...

I am going to demonstrate this at EclipseCon Europe 2011 at Wednesday. It's likely to go open source soon.

Sönke said...

Hi Jan,
At the moment I try out your view, but unfortunately I get an error in the GraphViewMapping.xtext file (line 15):
"Cannot find compatible feature typeGuard in sealed EClass DiagramMapping from imported package The existing reference 'typeGuard' has an incompatible type 'JvmTypeReference'. The expected type is 'JvmTypeReference' [org.eclipse.xtext.common.types.JvmTypeReference]."

I guess that it has to do with the version:
EMF 2.71
Xtext 2.2.1
Xtend 2.1.1

Any suggestions?

Unknown said...

Versions look OK. Did you try a clean build and change the grammar in an editor, save and revert the change?

Sönke said...

Ok, i build a new eclipse ide with emf and xtext. It "works". Now i'm trying to connect the ggv to my very simple dsl. after i created a gvmap i switch to my model and become this error:
"!MESSAGE org.eclipse.xtext.graphview.instancemodel.ModelInstantiator - Cannot resolve type guard for diagram type JvmParameterizedTypeReference: graphmodel.Graph"

Again the TypeGuard :-/

Unknown said...

By "clean build" I meant Project->Build->Clean all projects, not installing a new IDE.

Did you read the instructions in the README.TXT? You have to make the GGV aware your language. Also note the runtime plug-in containing the mapping, the stylesheet and the model to be visualized has to have a dependency on the graphview plug-in as well as on the DSL plug-in. There is also a PDE bug which might force you to move all dependencies in the MANIFEST.MF, save and restore them to make modifications in the root Eclipse - e.g. in your DSL - visibile to your runtime Eclipse.

I am afraid I cannot give you more support. As long as it's a prototype you have to find your way yourself.

Sönke said...

The xtext.ui plugin (which was generated from an ecore model) needs a dependency to the model plugin. Otherwise the classloader won't find the needed classes. :)