|
|
| (17 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| − | Note: this is still a work in progress...
| + | #REDIRECT [[Graphical Modeling Framework/Models/GenModel]] |
| − | | + | |
| − | == Mapping Model to Generator Model ==
| + | |
| − | The transformation of the generator model from the mapping 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.
| + | |
| − | | + | |
| − | [[Image:Map2GenOverview.png]] | + | |
| − | | + | |
| − | 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 [[Media:generation.png|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===
| + | |
| − | [[Image:gen_editor_generator.png|right]]
| + | |
| − | 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.
| + | |
| − | <br style="clear:both;"/>
| + | |
| − | | + | |
| − | ===Gen Plugin===
| + | |
| − | [[Image:gen_plugin.png|right]]
| + | |
| − | 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.
| + | |
| − | <br style="clear:both;"/>
| + | |
| − | | + | |
| − | ===Gen Diagram===
| + | |
| − | [[Image:gen_diagram.png|right]]
| + | |
| − | Clearly, the majority of our genmodel resides below Gen Diagram.
| + | |
| − | | + | |
| − | ===Nodes===
| + | |
| − | | + | |
| − | ===Links===
| + | |
| − | Link is represented by GenLink class in the model. It may reference the following model facets:
| + | |
| − | *''LinkModelFacet''
| + | |
| − | **TypeLinkModelFacet - for type based links
| + | |
| − | **FeatureLinkModelFacet - for feature based links
| + | |
| − | | + | |
| − | In addition to the properties derived from the other models GenLink provides:
| + | |
| − | *outgoingCreationAllowed (true) - it is possible to draw the link from source to target on diagram
| + | |
| − | *incomingCreationAllowed (false) - it is possible to draw the link from target to source on diagram
| + | |
| − | *viewDirectionAlignedWithModel (true) - when link is drawn from target to source it's direction in domain and notation models differ; when this property is true view in notation model will be "reoriented" to be aligned with direction in domain model
| + | |
| − | | + | |
| − | ===Labels===
| + | |
| − | The following classes describe labels in the model:
| + | |
| − | *''GenLabel''
| + | |
| − | **GenNodeLabel - inner node label
| + | |
| − | ***GenExternalNodeLabel - external node label
| + | |
| − | **GenLinkLabel - label near the link
| + | |
| − | | + | |
| − | GenLabel references model facet that defines label in domain model:
| + | |
| − | *''LabelModelFacet''
| + | |
| − | **FeatureLabelModelFacet - specifies single attribute
| + | |
| − | **CompositeFeatureLabelModelFacet - specifies more then one attribute
| + | |
| − | **DesignLabelModelFacet - marker to store label text in notation model
| + | |
| − | | + | |
| − | All properties are derived from the other models except DesignLabelModelFacet - it must be explicitly specified to support design labels as described in [[GMF_MapModel#Labels]].
| + | |
| − | | + | |
| − | == Code Generation ==
| + | |
| − | Currently, GMF uses JET to generate source files from its EMF models. The templates are located in the <code>org.eclipse.gmf.codegen</code> plug-in, under the <code>templates</code> 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.
| + | |
