Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » Non-containment for a child reference
Non-containment for a child reference [message #485154] Thu, 10 September 2009 16:15 Go to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
Hi,

In .gmfmap, suppose I have a Top Node reference with a child node
reference with a node mapping which is not contained in the Top Node
semantic Element.

In the child node reference, it's mandated that the 'containment
feature' should reside in the parent node mapping otherwise the
following validation warning will be given:

'containment feature' must be owned by 'Domain Meta Element' of it's
super type of this reference parent Node Mapping.

Is there a way to create a child reference (Actually to create inside a
compartment), which is contained in something else than the parent Node
mapping?

Thank you
Christophe
Re: Non-containment for a child reference [message #485351 is a reply to message #485154] Fri, 11 September 2009 13:30 Go to previous messageGo to next message
Alex Shatalin is currently offline Alex ShatalinFriend
Messages: 141
Registered: July 2009
Senior Member
Hello Christophe,

Youcan ignore warning, generate code and corect generated code to get/assign
child element to the appropriate parent one.
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).

-----------------
Alex Shatalin
Re: Non-containment for a child reference [message #485826 is a reply to message #485351] Tue, 15 September 2009 08:42 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
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.

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.

What's the solution for this?


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
>
>
Re: Non-containment for a child reference [message #485868 is a reply to message #485826] Tue, 15 September 2009 11:20 Go to previous messageGo to next message
Alex Shatalin is currently offline Alex ShatalinFriend
Messages: 141
Registered: July 2009
Senior Member
Hello Christophe,

> What's the solution for this?
Create single model reflecting parts "physically containing" each other and
a number of views of this model referencing different parts from a containment
tree...
As a view you can use manually assembled diagram (non-synchronized) or you
can create a diagram of "references" referencing different physical elements
from a containment tree.

-----------------
Alex Shatalin
Re: Non-containment for a child reference [message #486060 is a reply to message #485868] Wed, 16 September 2009 07:12 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
Thank you Alex,

What I read between the lines, is this manual coding work. Is it
correct to say, that with .gmfmap, I won't be able to do this?
(It's fine with me, I just need to know, so I can focus on a manual
coding solution).

BTW What is non-synchronized in this context?

Cheers Christophe



Alex Shatalin wrote:
> Hello Christophe,
>
>> What's the solution for this?
> Create single model reflecting parts "physically containing" each other
> and a number of views of this model referencing different parts from a
> containment tree...
> As a view you can use manually assembled diagram (non-synchronized) or
> you can create a diagram of "references" referencing different physical
> elements from a containment tree.
>
> -----------------
> Alex Shatalin
>
>
Re: Non-containment for a child reference [message #486181 is a reply to message #486060] Wed, 16 September 2009 15:39 Go to previous message
Alex Shatalin is currently offline Alex ShatalinFriend
Messages: 141
Registered: July 2009
Senior Member
Hello Christophe,

You can create a diagram and add corresponding elements there as a shortcuts
- this should be possible to achieve with current GMF state.
In addition with minor manual code/templates modifications you can represent
these elements as normal diagram elements.
Concerning non-synchronized diagrams - UI suggest you to set GenDiagram.synchronized
property to false in .gmfgen model, regenerate ode and see what's happening.
In few wordsa - once you create new domain model element in an underlying
domain model corresponding element will not appear on this diagram automatically.
Only elements created dierectly from this diagram will be there. The rest
is up to user - you can either use shortcuts to add more lements there or
use your own action for adding elements.

-----------------
Alex Shatalin
Previous Topic:Get ride of "Input methods" menu in ContextMenu
Next Topic:Save As menu item
Goto Forum:
  


Current Time: Fri Apr 26 14:32:26 GMT 2024

Powered by FUDForum. Page generated in 0.03928 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top