Graphical Modeling Framework/Concepts/Labels
Labels represent pieces of text possibly associated with icons on diagram surface. Text may be edited using inplace facility. There are many possibilities to construct labels but all of them are grouped in four usecases:
1. "feature based label"
Label is always defined in context of a diagram node or a link. If it's based on EClass from domain model then label may be used to represent attribute(s) of this class. Tooling will generate code that constructs label text and converts user input to the new value for attribute(s).
2. "design label"
It may be desirable to have a label that is not stored in domain model. Tooling may generate code that will use notation style (DescriptionStyle for example) to store label text in notation model.
3. "default label"
This is a read-only label with fixed text.
4. "custom label"
GMF runtime defines IParser interface that is responsible to provide label text and editing support. In this usecase toolsmith is supposed to provide his own IParser implementation.
The only possible label figure is Label. In generated diagram editor the actual figure may be Label from Draw2D or WrapLabel from GMF runtime. Attribute "text" of the figure is a text shown on diagram when parser is not available.
Position of label figure within model is important; it's used to determine whether label should be inner or external. Link labels are always external but node labels may be located whether inside node figure or "float" near it. If label figure is contained within parent node figure (directly or indirectly) it's inner label.
DiagramLabel element refers to the label figure and is being referenced by LabelMapping from mapping models. If "elementIcon" attribute is set then label use icon from EMF item providers.
LabelMapping and its subclasses define label within the mapping model.
Basic LabelMapping instance supports 3rd and 4th usecases. It has "diagramLabel" reference to graphical definition and "readOnly" flag.
FeatureLabelMapping extends LabelMapping to support 1st usecase by referencing domain attributes and providing format patterns:
- "features" reference: at least one attribute from domain model; all attributes should be defined within EClass of parent node / link
- "viewPattern" and "editPattern" attributes: MessageFormat patterns used to construct label text and parse user input
DesignLabelMapping is a LabelMapping flavour to handle 2nd usecase. Now it's empty but there should be a way to define view style used to store label text in notation model .
Two hierarchies describe labels in generator model: descendants of GenLabel used to express label presentation in context of parent node / link and descendants of LabelModelFacet that denote label semantic. GenLabel references LabelModelFacet by "modelFacet" reference thus linking them together.
Basic GenLabel has "elementIcon" flag copied from graphical definition and "readOnly" flag from the mapping model. GenNodeLabel and GenExternalNodeLabel are concrete classes that should be used to represent inner and external node labels respectively. GenLinkLabel is for the link labels and has "alignment" attribute derived from respective visual facet. GenChildLabelNode provides the same attributes as GenLabel but prefixed with "label" word; this class is used for nodes within list compartments.
Model facet reflects label usecase:
- "feature label": FeatureLabelModelFacet instance; properties "features", "viewPattern" and "editPattern" are taken from FeatureLabelMapping
- "design label": DesignLabelModelFacet instance
- "default label" and "custom label": no model facet (null)
In fact during mapping model to generator model transformation the following rules are obeyed:
- FeatureLabelMapping -> FeatureLabelModelFacet
- DesignLabelMapping -> DesignLabelModelFacet
- LabelMapping -> null