| Decorating domain model elements: checking Graphiti feasibility [message #1077850] |
Fri, 02 August 2013 08:19  |
 Niels Brouwers
Messages: 80
Registered: July 2009 |
Member |
|
|
Hi all,
We have already developed a graphical editor for our domain model. Furthermore, we have created several decorator models for this domain model. The goal of the decorator models are to store non-essential data about elements from the domain model in a seperated model, thus preventing the pollution of the domain model.
Now we would like to annotate the graphical representations of the domain model with data from the decorating elements stored in the deocrator models. Ideally, we would like to empower the user interacting with the domain model's graphical editor to dynamically select the annotation models to be visible on top of the domain model.
Example: assume that the domain model contains only one class Node and one reference Link to connect two Nodes. The Node is represented by a rectangle, the Link is represented by a line. Now, we have defined a meta-model for a decorator model, consisting of a LinkDecorator element that has only one attribute data:EInt and a reference to the Link element from the domain model. The data attribute is represented by a rectangular shape containing the value of the data attribute. Now we would like to show the graphical representation of the data atrribute next to the Link representation in the domain model's editor.
Given the above, we are facing two problems which are expected to not be trivial to be implemented using the current graphical framework for building graphical editors.
1. Creation of a graphical editor, where nodes from the diagram are originating (and persisted!) from more than one Ecore model? It is acceptable if only the domain model itself can be edited using the editor, and the decorator models are read-only.
2. Grouping of graphical representations from decorator models in layers and let the layer be visible according to the layer selection by the user of the editor?
Currently, the graphical editor for the domain model is implemented using GMF. We suspect the above use cases to be difficult to realize using GMF, and might therefore consider the migration of our domain model's graphical editor to another framework for implementing graphical editors, such as Graphiti.
Therefore, I would like to ask for a Graphiti expert to look at the use cases we need to realize and judge whether Graphiti is fit for this.
Thanks in advance!
Thanks in advance.
Kind regards,
Niels Brouwers.
|
|
|
| Re: Decorating domain model elements: checking Graphiti feasibility [message #1077959 is a reply to message #1077850] |
Fri, 02 August 2013 11:07  |
Michael Wenz
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany |
Senior Member |
|
|
Niels,
see my answers inline.
Michael
"Niels Brouwers" schrieb im Newsbeitrag
news:ktfq2a$9vf$1@xxxxxxxxe.org...
Hi all,
We have already developed a graphical editor for our domain model.
Furthermore, we have created several decorator models for this domain model.
The goal of the decorator models are to store non-essential data about
elements from the domain model in a seperated model, thus preventing the
pollution of the domain model.
Now we would like to annotate the graphical representations of the domain
model with data from the decorating elements stored in the deocrator models.
Ideally, we would like to empower the user interacting with the domain
model's graphical editor to dynamically select the annotation models to be
visible on top of the domain model.
Example: assume that the domain model contains only one class Node and one
reference Link to connect two Nodes. The Node is represented by a rectangle,
the Link is represented by a line. Now, we have defined a meta-model for a
decorator model, consisting of a LinkDecorator element that has only one
attribute data:EInt and a reference to the Link element from the domain
model. The data attribute is represented by a rectangular shape containing
the value of the data attribute. Now we would like to show the graphical
representation of the data atrribute next to the Link representation in the
domain model's editor.
Given the above, we are facing two problems which are expected to not be
trivial to be implemented using the current graphical framework for building
graphical editors.
1. Creation of a graphical editor, where nodes from the diagram are
originating (and persisted!) from more than one Ecore model? It is
acceptable if only the domain model itself can be edited using the editor,
and the decorator models are read-only.
Michael: EMF allows you to mix objects from several Ecore models into one
resource and Graphiti does not prevent that EMF option. It's also fine to
have read-only resources in the editor (decorator model resources in your
case), just note that there was in bug in Graphiti that caused an exception
in this case (see Bugzilla 412838); not fully sure if that is relevant in
your case.
2. Grouping of graphical representations from decorator models in layers and
let the layer be visible according to the layer selection by the user of the
editor?
Michael: Graphiti does not support different layers for shapes. Connections
are drawn on their own layer, but shapes just use the insertion order in the
parent's containment reference for their y-ordering.
Visibility is controlled in Graphiti by the existence of a shape and its
GraphicsAlgorithm (e.g. rectangle) and an invisible flag. In case they exist
and invisible is set to false, they appear in the diagram. Setting the shape
invisible will hide it; not however that is is a change to the diagram data,
that will leave the diagram changed.
Another option that just comes to my mind but I haven't trie dsomething like
that, would be to add the graphical representation of the rendering
decorators to another EMF resource and remove this resource from the editing
domain of the editor when they should not be shown (diagram editor refresh
would be needed afterwards). Not sure if that works though...
Currently, the graphical editor for the domain model is implemented using
GMF. We suspect the above use cases to be difficult to realize using GMF,
and might therefore consider the migration of our domain model's graphical
editor to another framework for implementing graphical editors, such as
Graphiti.
Therefore, I would like to ask for a Graphiti expert to look at the use
cases we need to realize and judge whether Graphiti is fit for this.
Thanks in advance!
Thanks in advance.
--
Kind regards,
Niels Brouwers.
|
|
|
Powered by
FUDForum. Page generated in 0.01925 seconds
] 
Search
Help
Register
Login
Home
