Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Graphical Modeling Framework/GenModel

Note: this is still a work in progress...

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.

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 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

Gen editor generator.png

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.

Gen Plugin

Gen plugin.png

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.

Gen Diagram

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 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.

Back to the top