Community
Participate
Working Groups
Created attachment 152316 [details] Diagram partitioning example Hello, I would like to suggest an enhancement to Eugenia so that DSLs with support partitioned diagrams can be created (top-level and subdiagrams). Per Dimitrios' request I put together an example, which was derived from the published state machine example. Basically, the state machine now has two types of states: Composite state, which work the same way as in the example, and partitioning states, which open a subdiagram upon double-click (click on the border, not on the label). Interestingly enough, after figuring out the proper metamodel, I only had to make one manual change to gmfmap. I tried to automate this change but just could not figure out the correct matching expression in the EOL file. 1) Select the node Top Node Reference <states:CompartmentState/CompartmentState> Node Mapping <compartmentState/CompartmentState> Child Reference <submachine:PartitioningState/PartitioningState> Node Mapping <PartitioningState/PartitioningState> 2) Set the property "Misc -> Related Diagrams" to "Canvas Mapping". You can diff the change if you regenerate the gmfmap and compare with the version that I submitted. Now to the logical modeling aspect: When a metamodel concept acts can be used as a partitioning subdiagram, it needs two representations: One as an element in the parent diagram, and one as a diagram pane. Therefore, I added two annotations to the top-level diagram node, namely @gmf.diagram (obvious) and @gmf.node (that's the new part). With subdiagrams of the same type, this approach should always be the same (to give the diagram concept two annotations). Now to the question of how to put this into an Eugenia concept. I see two possibilities, implicit and explicit: 1) Implicit: Whenever Eugenia discovers the two annotations @gmf.diagram and @gmf.node on a class, it will automatically deduct that this is thought to be a diagram partitioning construct and apply the change I described above automatically. 2) Explicit: Introduce new attribute to @gmf.node, such as isPartitioningElement=true/false or hasSubdiagram=true/false. The explicit version might also lend itself to future support for subdiagrams of different type. In the above example, only the class annotated with @gmf.diagram can be used for subdiagrams. But in a version with multiple diagram types, obviously any class could be a node in a parent diagram, and the diagram pane in the subdiagram representation. I am planning at some point in time to work on subdiagrams of different type. I belive that Eugenia is predestined for such a feature because it would require generating multiple sets of gmfxxx files, which then require manually overridden configuration. So Eugenia with it's full regeneration approach could greatly help making that manageable. If you would like to discuss aspects of my proposal or need more information, please contact me at cwienands@gmx.net. Greetings, Christoph
If it helps, this Ecore2GMF.eol file will do the subdiagram customization for the attached example. var nodeMapping := GmfMap!NodeMapping.all.selectOne nm|nm.domainMetaElement.name = "PartitioningState"); var canvasMapping := GmfMap!CanvasMapping.all.first(); nodeMapping.relatedDiagrams.add(canvasMapping);
After playing around with the example that I submitted, I noticed that there are still some issues when saving either the top or the subdiagram. In either case, changes to the other diagram are overwritten (or you have to discard the previous changes). The only way to work with this right now is to save the top-level diagram before opening the subdiagram. Once done in there, save it and go back to the top-level diagram. This might have to do with an editing domain, or two different editing domains where change notifications are not passed around. But this is just a wild guess right now.
I too have noticed this... Subdiagrams are quite difficult to get around in GMF. I hope I'll get a bit of free time in February and look into this. Or we can wait for Graphiti (http://www.eclipse.org/proposals/graphiti/) which sounds a bit more promising ;)
