Graphical Modeling Framework/GenModel
Note: this is still a work in progress...
Mapping Model to Generator Model
The transformation from the mapping model to the generator model is described here. If you have looked at the *.gmfgen model that was produced in the tutorial, you'll notice that a quite a few things were created in the process. A general overview of the transformation can be seen in the diagram below, which is followed by detail on each step.
From this diagram, you can see that the selected mapping model is first opened and validated. The canvas is processed, followed by each node, and then each link. Finally, the new generator model is saved and validated.
During the processing of the canvas, a GenModelMatcher is created and the EMF genmodel for the domain model is located. If you look at the generator model itself, you will see a large number of properties related to the canvas need to be set, in addition to the plug-in used to deploy our editor. The names given to these properties are determined by a naming mediator. A DiagramRunTimeClass is selected and is the bridge we need to the GMF runtime notation model. In fact, if you open the *.gmfgen model in the EMF editor, you will see the notation model loaded, along with the domain model and ECore model.
During the processing of the nodes, another set of Gen* classes are initialized, in addition to *ModelFacet classes, which hold a reference to the domain model element represented by the node. Runtime notation model counterparts are selected, and if the node has an edit feature, the appropriate facet, GenNodeLabel, etc. are added. One of the more interesting aspects of the genmodel creation is found in how figures are generated by the FigureGenerator. At this stage, JET is used to produce the content of an inner class viewmap, contained in the *EditPart. Finally, tooling for the node is processed, as are child nodes and compartments.
A Look at the GenModel
As mentioned previously, there is still a bit of refactoring being done to the generator model, so the description that follows may not be entirely accurate if you are using a later build of GMF. That said, we'll now to explore the generator model to see what options are available to us, with respect to our ability to control the code generation to follow.
Gen Editor Generator
At the root of the *.gmfgen model, you will find the Gen Editor Generator element. This element contains elements for the diagram, the plug-in to be generated, and the editor itself. As shown in the figure, this element will allow you to alter the diagram and domain file extensions, set the package name prefix for the generated plug-in, and opt to store your diagram and domain information in a single file. The last option is set to false by default.
The next element we'll look at is Gen Plugin, as there isn't much to talk about in Gen Editor View. As you might expect, here's where you can set your provider name, the plug-in name and ID, activator class name, etc. If you select true for 'Printing Enabled,' the generator will add a contribution to the globalActionHandlerProviders runtime extension-point allow you to print your diagrams. With the property set to false, the print option will be disabled. Note that printing is currently available for Windows.
Clearly, the majority of our genmodel resides below Gen Diagram.
Compartments and Layout
With reference to the mindmap example, the threads placed in topic Node follows the XYLayout that enables us to drag the nodes around. But in default, when u create a compartment the nodes that are to be placed into it follow the List Layout by default. By making List Layout = false, the XYLayout is enforced. You can find this option in gmfgen. I have enclosed the snapshot where to find it and how the Threads would look with this default layout.
Currently, GMF uses JET to generate source files from its EMF models. The templates are located in the
org.eclipse.gmf.codegen plug-in, under the
templates directory. They are arranged in commands, editor, parts, policies, and providers folders. Each is loaded by the EmitterFactory and utilized by the main Generator class. Some refactoring is expected in this area, as is the potential to leverage an alternative template technology.
Targeting the Runtime
As GMF provides a large, extensible runtime, many options exist for generation. The extent to which the generation framework leverages runtime extension-points and APIs is expected to vary according to the toolsmith's needs and option settings. What follows below is a description of how the generation framework targets the runtime at the present time, although improvements are ongoing. The tutorial's Mindmap example will be used to provide the context of the discussion.