Jump to: navigation, search

Difference between revisions of "Graphical Modeling Framework/Concepts/Labels"

(Diagram Labels)
Line 16: Line 16:
  
 
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.
 
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.
 +
 +
==Related requests in bugzilla==
 +
 +
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=161380 Refactor labels in GMF 2.0]
 +
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=150816 Support "design" labels for nodes backed up with domain element]
 +
*[https://bugs.eclipse.org/bugs/show_bug.cgi?id=138179 Allow to define labels based on attributes of referenced objects]

Revision as of 06:40, 20 October 2006

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.

Related requests in bugzilla