Difference between revisions of "Graphical Modeling Framework/Models/GMFMap"

From Eclipsepedia

Jump to: navigation, search
m (GMFMap Hints moved to GMF MapModel Hints)
Line 1: Line 1:
== GMFMap's POI (points of interest ==
+
== Scenarios ==
 +
* Show children elements from non-containment feature
 +
*: Generally, '''Containment Feature''' of '''Node Reference''' specifies where to put newly created child to, while '''Children Feature''' is there to find out where to take children from to display them. It's quite often that these two are the same, hence '''Children Feature''' defaults to value of '''Containment Feature'''.
 +
*: To show children from feature different from the one they are contained with, simply set it as '''Children Feature'''. You'll need to specify '''Containment Feature''' as well.
  
=== Label Mapping Properties ===
+
* Endless/recursive hierarchies
* View Pattern
+
*: ChildReference not necessarily owns node mapping, it's possible to point to existing NodeMapping, defined elsewhere. Reusing NodeMapping allows to create endless hierarchies of elements, e.g. ''StateMachine'' owns ''State'' (via ''states'' containment ref), and ''State'' owns other ''State''s (via ''substates'' containment). To get endless ''State'' hierarchy define '''TopNodeReference''' with ''states'' set as '''Containment Feature''', which owns '''NodeMapping''' (referencing ''State'' and appropriate diagram node and palette element). '''ChildReference''' of the '''NodeMapping''' specifies ''substates'' as '''Containment Feature''' and the owning '''NodeMapping''' as its '''Referenced Child'''. That is.
* Edit Pattern
+
  
== FAQ ==
 
* Show children elements from non-containment feature
 
* Endless hierarchies
 
 
* Use same creation tool to create various diagram elements
 
* Use same creation tool to create various diagram elements
 +
*: Few mappings can point to same tool definition in the .gmftool model. Transformation (.gmfmap -> .gmfgen) is smart enough to recognize that and creates only one tool capable of creating several metamodel types. It's not possible to use the same tool to create both nodes and links, though.
 +
 +
== GMFMap's POI (points of interest) ==
 +
 +
=== Node and Link Mapping ===
 +
These elements keep
 +
 +
=== Concept of Node References ===
 +
* '''Containment Feature'''
 +
*: - ''EReference'' with ''containment'' attribute set to '''true'''.
 +
* '''Children Feature'''
 +
*: - generally, non-containment ''EReference'', the same as '''Containment Feature''' unless explicitly set. Usually, this feature is read-only filtering view to values in '''Containment Feature'''(Think of ''EClass.eAttributes'' and ''EClass.eOperations'' - both ''EOperation'' and ''EAttribute'' are owned via ''eClass.eStructuralFeatures''). Though this ''EReference'' may be containment reference different from '''Containment Feature''', it doesn't sound like reasonable use-case
 +
* Child
 +
*: Shows actual node mapping taken as child (either from '''ownedChild''' or '''referencedChild''')
 +
*: There's no much sense to set both ownedChild and referencedChild properties.
 +
 +
=== Label Mapping Properties ===
 +
* View Pattern - <code>java.text.MessageFormat</code>
 +
* Edit Pattern - <code>java.text.MessageFormat</code>

Revision as of 13:18, 10 July 2006

Contents

Scenarios

  • Show children elements from non-containment feature
    Generally, Containment Feature of Node Reference specifies where to put newly created child to, while Children Feature is there to find out where to take children from to display them. It's quite often that these two are the same, hence Children Feature defaults to value of Containment Feature.
    To show children from feature different from the one they are contained with, simply set it as Children Feature. You'll need to specify Containment Feature as well.
  • Endless/recursive hierarchies
    ChildReference not necessarily owns node mapping, it's possible to point to existing NodeMapping, defined elsewhere. Reusing NodeMapping allows to create endless hierarchies of elements, e.g. StateMachine owns State (via states containment ref), and State owns other States (via substates containment). To get endless State hierarchy define TopNodeReference with states set as Containment Feature, which owns NodeMapping (referencing State and appropriate diagram node and palette element). ChildReference of the NodeMapping specifies substates as Containment Feature and the owning NodeMapping as its Referenced Child. That is.
  • Use same creation tool to create various diagram elements
    Few mappings can point to same tool definition in the .gmftool model. Transformation (.gmfmap -> .gmfgen) is smart enough to recognize that and creates only one tool capable of creating several metamodel types. It's not possible to use the same tool to create both nodes and links, though.

GMFMap's POI (points of interest)

Node and Link Mapping

These elements keep

Concept of Node References

  • Containment Feature
    - EReference with containment attribute set to true.
  • Children Feature
    - generally, non-containment EReference, the same as Containment Feature unless explicitly set. Usually, this feature is read-only filtering view to values in Containment Feature(Think of EClass.eAttributes and EClass.eOperations - both EOperation and EAttribute are owned via eClass.eStructuralFeatures). Though this EReference may be containment reference different from Containment Feature, it doesn't sound like reasonable use-case
  • Child
    Shows actual node mapping taken as child (either from ownedChild or referencedChild)
    There's no much sense to set both ownedChild and referencedChild properties.

Label Mapping Properties

  • View Pattern - java.text.MessageFormat
  • Edit Pattern - java.text.MessageFormat