| GMF "philosophical" question [message #490579] |
Fri, 09 October 2009 09:33  |
Eclipse User |
|
|
|
Originally posted by: xmoneva.gmail.com
Set-up:
The model used in the experiment is as follows:
(later modified like this: add containment)
Root<>---0..1->Block-----
Root<>---0..1->Block<>--
|_0..*__|
|_0..*__|
Where, Root represents the diagram element (the canvas) and the Block
represents a tree-like structure.
Small experiment:
Step1: Using GMF, the set-up is modeled in ecore and then all the steps
performed till achieving diagram editor, which allows graphical modeling of
directed acyclic graphs using our simple DSL.
Step2: Change the ecore model as shown in the set-up (change the
self-reference of the Block to containment). DO NOT regenerate the diagram
editor (only the model) and run. It does not crash! It works! But the graph
is not graph any more....
Philosophical question:
Directed acyclic graph (you can use the DSL above). Always (intuitive for
the user) it is presented as nodes and edges and it is a tree-like
structure. For example:
Node4
Node2<
Node1< Node5
\
Node3
There are two implementations possible. 1. Using containment. 2. Using
references.
Now the question. Based on the experiment, GMF does not allow to choose the
implementation, if you have preference (fixed) graphical representation. My
humble opinion is that in MVC, the model and the view are decoupled via the
controller. So that the model structure and semantics in independent from
the view representation and semantics.
Small example why I may have preference to one of the approaches (case 1):
the model represents DSL. The DSL is containing the structure and the
semantics of the domain. If my domain is "car", I expect that my car
contains 4 wheels and 3/5 doors, etc. But the view may be still graph-like
structure.
So, am I wrong (missing something) in applying GMF? Is there really such
assumption while generating the view? Can I overcome it still using GMF or I
have to use separately EMF and GEF?
|
|
|
|
|
| Re: GMF "philosophical" question [message #490689 is a reply to message #490579] |
Fri, 09 October 2009 17:26  |
 Alex Shatalin
Messages: 141
Registered: July 2009 |
Senior Member |
|
|
Hello Hristina,
Well, you have to regenerate diagram code on changing domain model.
I even suggest you to re-run .gmfmap->.gmfgen transformation before..
Sometimes it can happen that you end up with workign code, but sometimes
not (try for example deleting self-reference of the Block and run old diagram
code..) ;-)
Talking seriously, this use case is covered by GMF.
If you'd like to visualize tree structure on GMF diagrams there are two options
for it now:
1. Create following domain structure and map it to the diagram like:
- One Root element in a domain model will be represented as "canvas" and
contains a) one RootBlock 2) * other Blocks.
- RootBlock domain model element is mapped as top-level diagram node, extending
Block domain model element
- Block domain model element is mapped as top-level diagram node, keeping
* non-containment multiple reference to other Blocks
- Reference from one Block to another one is mapped as a diagram link.
In this case there is a common container of all the domain model elements
"Root" and actual tree structure will be by non-containment links from one
Block to another Block (you have to ensutre there is no cycles manually).
2. Create following domain structure and map it to the diagram like:
- One Root element in a domain model will be represented as "canvas" and
contains one RootBlock
- RootBlock domain model element is mapped as top-level diagram node, extending
Block domain model element
- Block domain model element is mapped as top-level diagram node (having
no containment feature specified - there is not containment feature for this
node in Root anymore), keeping * containment multiple reference to other
Blocks
- Containment reference from one Block to another one is mapped as a diagram
link.
So, you probably can see the differenced in domain model introduced there
while moving from 1. to 2. and I've highlighted a changes you have to made
in .gmfmap model in order to correctly adopt it to this use case. As a result
you'll have exactly same diagram... You should not care about cicles there
anymore - EMF will do it for you keeping in mind "containment" feature specifics.
As a result you'll have tree structure represented in your model instead
or plain list of nodes connected with references...
You probably would like to move from 1. to 2. I do not understand the question
fully... To komplete this migration you have to modify .ghmfmap file in accordance
and regenerate .gmfgen + code from there.. Diagram code generated for domain
model described in 1. is obsolet once you decided to use approach 2....
-----------------
Alex Shatalin
|
|
|
Powered by
FUDForum. Page generated in 0.03666 seconds
] 
Search
Help
Register
Login
Home
