Why you should consider Sphinx for your modeling projects.

The Sphinx project is one of the most interesting new projects on eclipse.org and provides important infrastructure for modeling projects. However, it might not be immediately visible from the project description what it does. Here is an example on how it can help you when writing graphical editors (in our case with Graphiti).

We face two questions:

  • How to deal with models, that consist not only of one model file, but is actually split up between several models
  • How to synchronize different views etc in Eclipse.

The first question immediately comes up for models that can be split per definition (as in AUTOSAR, where a model can be defined in several .arxml files). But even if you think that your domain model is only stored in one single file – by introducing one or more Graphiti diagrams (which are stored as EMF models), you have to combine these with the domain model.

Multiple copies of the domain model

The second question might not be immediately obvious, but you will notice it soon. The different views in Eclipse are not guaranteed to use the same in-memory representation of a model file, making synchronization difficult:

The Navigator in the Explorer View and the Diagram Editor might both load the domain model with standard EMF mechanism. But that results in each of the view having their own specific copy of the model independent of the other view. That means that an object “Wiper” is available in memory for the navigator and a different object “Wiper” at another memory location for the graphical editor.

2013-01-09_10h44_24

That has several consequences:

  • Changes in one editor are not reflected in the other editor immediately, since these are obviously different objects in different resources
  • Synchronizing is done on resource save – the other editor detects that the resource has changed. This is annoying, because for the explorer this will result in the contents of the model being collapsed and you have to open everything again. And in the Graphiti editor, you will be notified that the underlying resource has changed and asked if you would like to discard your changes – even if your diagram does not have any of the affected domain model elements in it.
  • Drag and Drop needs extra effort. If you drag one object from one view to another, you cannot just rely on the “==” operator, because even if it is the same domain model object, it will just be another copy. So you have to work with URIs or other approaches to find the domain model object you are being passed in your resource.

Sphinx to the rescue

Sphinx helps you with that. Sphinx provides extension points and an API to define which model files should be considered together as one model and then you just ask Sphinx for the model – everything else is taken care of.

2013-01-09_10h44_58

Code details

There is an example integration of Graphiti editor in the Sphinx experimental directories – but we had to add additional things, since we derive from the plain Graphiti way at several places. The standard experimental Graphiti / Sphinx integration works on the Graphiti EMF namespace. However, since we derived from that, we need to tell Sphinx which models should be loaded to Autosar:

2013-01-09_10h36_45

2013-01-09_10h28_30By providing the TargetMetaModelDescriptorProvider we tell Sphinx that our models should be loaded into the models defined by a target meta model descriptor. The default Sphinx/Graphiti integration is quite elaborate, but for us, we always want to be loaded into AUTOSAR model. So the implementation of the class is quite simple – by returning the Autosar40 model descriptor:

The target meta model is related to the model that should be added through the contentType attribute of targetDescriptorProvider(see screenshot above). Obviously, we need a Descriptor for our own GraphitiAutosar Metamodel (which is derived from Graphiti Diagram ecore):

2013-01-09_10h31_42

 

Finally, we define a content-type for our diagram extensions:

2013-01-09_10h38_452013-01-09_10h39_10In addition, we register a specific editor through org.eclipse.ui.editors:

2013-01-09_10h40_47Note the line “class” is

which is a modification done to actually invoke Graphiti editors with Guice.

After this implementation, changes done in the diagram are immediately reflected in the Graphiti editor (and vice-versa) and the drag-and drop code can be much simplified by checking with the “==” operator.