Graphical Modeling Framework/Versions/GMF 2.1
Graphical Modeling Framework 2.0 New and Noteworthy items
...broken down by milestones, (see GMF Project Plan for more details)
Back to Graphical Modeling Framework
- 1 GMF Release 1.0 (June 30, 2006)
- 2 2.0 M1 (September 04, 2006)
- 3 2.0 M2
- 4 2.0 M3
- 5 2.0 M4
- 6 2.0 M5
- 7 2.0 M6/RC0
GMF Release 1.0 (June 30, 2006)
2.0 M1 (September 04, 2006)
Merging for plugin.xml and plugin.properties
Protected region is defined in plugin.xml where users may add their extensions. These extensions will be preserved on diagram editor regeneration. Properties file plugin.properties is merged using EMF merger for property files.
Add custom edit policies in gmfgen model
Custom behaviour may be added to diagram element using CustomBehaviour object. In generated code this means inserting custom edit policy in edit part of diagram element.
Default mapping creation wizard creates canvas mapping
Mapping wizard generated by EMF is enhanced by adding pages to select domain model, diagram canvas and palette. If specified domain, graphical and tooling definition models are loaded and canvas mapping that binds them is added.
Unit-tests covering following parts of generated code were implemented:
- toolbar tools
- diagram and model resources saving
- diagram node hierarchy creation
- compilation test for user models with “instance class name” property specified
Wizards to reconcile graphical and tooling definition models
Wizards that infer graphical and tooling definitions from domain model now can reconcile results with existing models. One may start such wizards explicitly using File -> New -> Other menu or use GMF Dashboard where 'Derive' actions switch wizards to reconcile mode if graphical and tooling definitions are selected for the project.
Diagram content could be provided below diagram file node in standard Project Explorer Eclipse view. Read-only properties of underlying semantic element available for single-element selection.
GenNavigator metaclass was added to GMF GenModel. Default Navigator structure will be created automatically by GMF MapModel - GMF GenModel transformer, so it is necessary to run this transformation and regenerate the code from newly created GMF GenModel to get Navigator generated.
ILinkHelper implementation generated
Project Explorer selection could be synchronized with open diagram selection if "Link open editors with content in the Navigator" button pressed on Project Explorer toolbar. To implement this functionality additional class <DiagramPrefix>NavigatorLinkHelper will be generated.
Option to create a GenModel if it's missing
If during transformation appropriate .genmodel was not detected, toolsmith could browse for existing with an option to either create a new blank model with regular defaults or to launch EMF wizard to create .genmodel manually.
Basic support for diagram partitioning
GMFMap's MappingEntry has a link to other CanvasMappings now. Once it's defined, transofrmation attaches OpenDiagramBehaviour to appropriate GenNode, and there's OpenDiagramEditPolicy generated that tries to open editor for the diagram.
Do not generate superfluous code in few particular cases
CanonicalEditPolicy is no longer generated for elements without immediate children to be updated. GraphicalNodeEditPolicy is generated only when there are links with inverted direction. You may notice that these policies are no longer registered within node's createDefaultEditPolicies() method after regeneration and remove respective classes. Alternatively, if you didn't change the edit policies' code, you may remove all classes extending CanonicalEditPolicy and GraphicalNodeEditPolicy in your plug-in and regenerate the code. This will leave only those policies that are needed.
Corresponding diagram will be opened in editor (activated if already opened) on double-clicking to the diagram node in diagram file content sub-tree provided to the Project Explorer Eclipse view. Useful for the situation then several diagrams are stored in the same diagram file (see Basic support for diagram partitioning).
Mapping Model Visual Editor
Diagram editor that uses GMF mapping model as domain model. In other words now you may design diagram editor in diagram editor ))) You need org.eclipse.gmf.map.editor plugin.
Automatic diagram editor refresh
Generated diagram editor will be automatically refreshed on any changes in the eclipse resource subsystem made outside of the editor without reopening. Examples of such changes are:
- modifications made in domain model inside EMF-generated tree editor
- modifications made on another diagram created in the same diagram resource using diagram partitioning feature
- diagram/domain model resource rename/move in the workspace
- changes in diagram/domain resource downloaded from version control
Corresponding dialogs will appear on following editor activation/saving if editor state was dirty at the moment of changes in the eclipse resources subsystem.
Xpand Template Engine
JET alternative which is much more handy for complex template we've got in GMF is now part of SDK. Figure generation (org.eclipse.gmf.graphdef.codegen) has neen rewritten with Xpand. For more details on Xpand read the [paper] from Eclipse Summit Europe.
Merge for plugin.xml
Protected regions added in M1 were replaced with per-extension 'generated' marker in form of XML processing instruction. Any tag not marked as generated will be preserved during merging. Extensions marked as generated are matched using respective point id (note, multiple extensions for same point may have merging issues, we are going to further refine matching using extension ids or additional attribute in the processing instruction).
It's possible to generate diagram editor as RCP application based on full GMF runtime:
TypeLink creation commands are generated as separate classes
Separate class implementing link creation command will be generated for each TypeLink. This is first part of the fix for request #157683 significantly simplifying generated code modification in case of TypeLinks connecting abstract super-class(es) of several domain elements.
Since in previous version of generator link creation commands were generated as inner-classes inside source/target ???NodeItemSemanticEditPolicy, these classes will be removed by next code generation. If some of the link creation commands were marked as "@generated NOT" and customized by user then corresponding code should be manually stored prior to the code generation and then moved into the newly generated ???TypeLinkCreateCommands.
You have to re-transform .gmfgen model from .gmfmap model to generate correct code.
Compartment Scrolling Thumbs
To resolve compartment scrolling issues request #110971, transparent compartment scrolling thumbs have been added to make the scrollbars more usable on compartments:
SemanticNode creation commands are generated as separate classes
Separate class implementing node creation command will be generated for each SemanticNode (not pure design one). This is a second part of the fix for request #157683. It reduces a number of generated inner-classes then the same GenNode references as a child node from several containers as a result simplifying generated code modifications.
Since in previous version of generator node creation commands were generated as inner-classes inside ???NodeItemSemanticEditPolicy, these classes will be removed by next code generation. If some of the link creation commands were marked as "@generated NOT" and customized by user then corresponding code should be manually stored prior to the code generation and then moved into the newly generated ???CreateCommands.
You have to re-transform .gmfgen model from .gmfmap model to generate correct code.
Fully qualified names in templates are organized as imports after generation
Organization of import statements was added recently to gmf generator (request #165864). So now most of qualified names you use in templates will be moved to java-imports after generation. Therefore there is no need in importManager calls from JET anymore, and it is supposed to be a good style using the fully qualified names right as they are. Besides, being a post-generator facility, this applies to xPand templates as well as JET ones.
Diagram editor genmodel (gmfgen) now describes default diagram preferences (GenDiagramPreferences class) and preference pages.
Default diagram preferences are reflected in generated DiagramPreferenceHint class that records them in preference store.
Preference page may be one of the standard preference pages (Appearance, Connections, etc.) or custom one with class name specified in gmfgen model.