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.
Difference between revisions of "GMF: Synchronized Container Use Cases"
(→Synchronized containers) |
(→Synchronized element) |
||
| Line 22: | Line 22: | ||
''CanonicalConnectionEditPolicy'' – abstract subclass of ''CanonicalEditPolicy'' supporting outgoing element-based diagram links synchronization. | ''CanonicalConnectionEditPolicy'' – abstract subclass of ''CanonicalEditPolicy'' supporting outgoing element-based diagram links synchronization. | ||
| − | == Synchronized | + | == Synchronized elements == |
| + | Each ''synchronized element'' should always represent up to date content of the corresponding domain model element. Following cases should be covered: | ||
| + | |||
| + | - domain model was changed in external editor in a way that new child diagram element could be recognized (new child domain element added) - diagram editor content should be updated with new child diagram element on next diagram opening. | ||
| + | |||
| + | - domain model was changed externally in a way that existing child diagram element should be removed (child domain element removed) – corresponding child diagram element should be removed on next diagram opening. | ||
| + | |||
| + | - domain model was changed by user code, new child diagram element could be recognized – diagram editor content should be updated with new diagram element on receiving corresponding EMF notification. | ||
| + | |||
| + | - domain model was changed by user code, child diagram element removed – corresponding child diagram element should be removed on receiving corresponding EMF notification. | ||
| + | |||
| + | - if same domain model element could be represented on diagram as a different diagram elements (node-1 or node-2) based on domain model properties and domain model was changed externally/by user in a way existing domain model element should change diagram representation (not be recognized as node-1 anymore, but should be recognized as node-2) – existing node-1 should be replaced by node-2 on next diagram opening/receiving EMF notification. Node-2 should get size/position of node-1 and all the rest of applicable Styles. | ||
| + | |||
| + | - if this ''synchronized element'' was just created by update process (''CanonicalEditPolicy'') and some child diagram elements could be recognized from the underlying domain model element then update should be triggered for this ''synchronized element'' to create corresponding diagram elements. In other words, on any model changes diagram should be updated to always represent actual domain model content. | ||
== Synchronized links == | == Synchronized links == | ||
Revision as of 13:48, 12 April 2007
Contents
Preface
In the current state GMF supports two modes of diagram code generation - synchronized and non-synchronised. Toolsmith is able to switch between these two modes by changing GenDiagram.synchronized property. There were a number of discussions concerning diagram behavior in different situations according to the current mode. The idea of this document is to summarize existing requirements to simplify upcoming features development. Once this document will be finalized, corresponding changes should be introduced into the code generator and the runtime part if necessary.
This document will cover common use cases for different type of synchronized/non-synchronized diagrams from the end-user point of view and highlight corresponding places in code generator/runtime to be used to in corresponding conditions.
Definitions
synchronized element – diagram node or diagram itself always representing actual domain (semantic) model contents. i.e. all the child diagram nodes recognized from the underlying domain model.
canonical container – synchronized element.
non-synchronized element – diagram node or diagram itself representing only selected child diagram nodes recognized from the domain model.
synchronized diagram – diagram itself, all the diagram nodes and sub-nodes are synchronized elements
element-based link – diagram link associated with the element in a domain model connecting link source with link target domain model elements.
reference-only link – diagram link representing reference in a domain model. This reference contained in a link source domain model element and pointing to the link target domain model element.
CanonicalEditPolicy - abstract class in GMF runtime implementing EditPolicy and encapsulating set of functionality useful for synchronizing diagram element contents with the domain model element contents.
CanonicalConnectionEditPolicy – abstract subclass of CanonicalEditPolicy supporting outgoing element-based diagram links synchronization.
Synchronized elements
Each synchronized element should always represent up to date content of the corresponding domain model element. Following cases should be covered:
- domain model was changed in external editor in a way that new child diagram element could be recognized (new child domain element added) - diagram editor content should be updated with new child diagram element on next diagram opening.
- domain model was changed externally in a way that existing child diagram element should be removed (child domain element removed) – corresponding child diagram element should be removed on next diagram opening.
- domain model was changed by user code, new child diagram element could be recognized – diagram editor content should be updated with new diagram element on receiving corresponding EMF notification.
- domain model was changed by user code, child diagram element removed – corresponding child diagram element should be removed on receiving corresponding EMF notification.
- if same domain model element could be represented on diagram as a different diagram elements (node-1 or node-2) based on domain model properties and domain model was changed externally/by user in a way existing domain model element should change diagram representation (not be recognized as node-1 anymore, but should be recognized as node-2) – existing node-1 should be replaced by node-2 on next diagram opening/receiving EMF notification. Node-2 should get size/position of node-1 and all the rest of applicable Styles.
- if this synchronized element was just created by update process (CanonicalEditPolicy) and some child diagram elements could be recognized from the underlying domain model element then update should be triggered for this synchronized element to create corresponding diagram elements. In other words, on any model changes diagram should be updated to always represent actual domain model content.