Christophe,
Comments below.
Christophe Bouhier wrote:
Hi Alex, (CC emf group, as this is also an EMF question).
I have played around with your suggestion, see inline experience below.
Maybe the deeper question is, how do I create a semantic model of nested
elements (Of the same type) which form a tree structure. The tree
elements need to be re-usable (So if contained they woudn't be reusable,
and need to be therefor non-contained references which causes the
problem described earlier).
E<--E<--E
^
|
E<--E
^
|
E
<-- is non-containment reference.
This model, has to be gmf friendly so to say and allow the nested tree
to be visualized in compartments.
One could argue that GMF should not require the model to use containment
just to induce a particular view on that model.
It seems to me, that this problem is a generic pattern others must have
run into. When modeling a system (i.e. a computer), it has parts which
has subparts etc.. forming the tree structure. Of course a part could be
used in another computer product. When I use a containment feature , it
can't be used in multiple computers. (In EMF, the part would be moved
around). I could make a copy of the part, but this means a lot of
duplication.
Of course that's how the parts work in the real world. :-P
What's the solution for this?
You'd have a parts manifest that contains them somewhere and then you'd
reference those things. Inducing a view on a model ought to be a
separate problem, e.g., the item providers by default induce a tree view
on the containment references but allow you to induce one for any type
of reference.
many thanks Christophe
Alex Shatalin wrote:
Hello Christophe,
Youcan ignore warning, generate code and corect generated code to
get/assign child element to the appropriate parent one.
Ok, when ignoring the warning, the gmfgen gets produced, the code breaks
in one code file:
1: xxxDiagramUpdater.java
getElementElementCompartment_7001SemanticChildren(...)
This makes sense, the semantic children for element are not contained in
this domain element but "somewhere else", I could change this to
"somewhere else".
Note: I realize it's not a very good idea to name elements "Element" in
the semantic model :-)
Anoter option is to create derived feature in parent domain model
element, implement it in EMF so it will assign child element to the
appropriate container and use this feature as a containment one
(.gmfmap editor does not allo it, but you can do that by changing
text file).
Need to dive into this, not sure how a derived feature can be created
with an .xsd meta model, or do I adapt the feature in .ecore?
-----------------
Alex Shatalin