Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » Shortcut for 1:1:n containment reference chains in NodeMapping/ChildReference
Shortcut for 1:1:n containment reference chains in NodeMapping/ChildReference [message #216764] Thu, 29 January 2009 19:01 Go to next message
Christian Muth is currently offline Christian MuthFriend
Messages: 24
Registered: July 2009
Junior Member
Hi all,



Few days ago, I asked another question here on the group: "ListLayout in
compartments not working as expected".

After some investigation and playing around, i found a solution to my
original question, although the actual problem is titled differently.


To make explanation easier, let's assume my domain model is as follows:

1 : 1 : 0..n
A => B => C
=> C
=> C

So one A owns exactly one B which in turn owns several Cs.

In my example, the core of the problem with my node mapping for A was
that i had to use a rectangle inside A's compartment (for node mapping
of B although not showing anything). One can't directly place
ChildReferences of C into NodeMapping of A, a NodeMapping for B is
necessary to hold the ChildReferences:

NodeMapping A
ChildReference A.b : B
NodeMapping B
ChildReference B.cs : C
etc.

Rectangle B in turn should have been the container for the children C
and should have grown to A's compartment dimensions, but Cs should be
placeable freely inside B. B does not have attributes to be displayed
though.

I couldn't figure out how to get this behavior so i started a different
approach:

I solved this issue by creating kind of "shortcuts" in my EMF domain
model so that i can ask A for instances of C. (containment, derived,
transient references from A->C) - Remember: A->B is 1:1 containment
reference. These references have to be containments to be selectable in
..gmfmap.

The implementations for these derived features in EMF's AImpl.java
simply forward to C's getter methods:

in AImpl:
/**
* generated NOT
*/
public EList<C> getCs() {
return this.getB().getCs();
}

So the domain model doesn't get screwed up.


To get this working, I needed a Feature Seq Initializer on the
NodeMapping of A which creates the B instance on the fly when an A Node
is created in the diagram. Generated initialization code for this goes
into ElementInitializers class.

So i was able to remove standalone Figure Descriptor for Rectangle B and
its Node definition completely - instead i created a Rectangle inside
Rectangle A, created a ChildAccess for that inner Rectangle and used it
in A's compartment "Accessor" property.

Now i placed a BorderLayout into Rectangle A, put BoderLayoutData
(BEGINNING, vertical=true) as child into A's Label and created a
BoderLayoutData (FILL, vertical=true) inside A's inner Rectangle (which
is the compartment rectangle).

Now it works as desired & A's compartment's contents (which are XYLayout
due to ListLayout=false in .gmfgen) are also layouted well by the
"Arrange All" feature.


So my problem comes down to the fact(?) that you need to reflect your
model's containment hierarchy in the .gmfmap and that one isn't able to
shortcut the A->B 1:1 containment references so that the ChildReference
of C can directly be placed inside A.

I have lots of these 1:1 containment references like A->B in my domain
model, with B not only having one but many referenced types like C. I
also have many occurrences of

A -> B -> C -> D
1 : 1 : 1 : n

It would really be quite a painful task to address this issue with the
workaround described here: shortcutting these containment hierarchies
from A -> D.

Might it eventually be possible to extend GMF to support this? If so,
could someone with more experience in GMF please point me to the places
to look/modify? Or does GMF already support this?

If this might be useful for others as well, I would prefer sharing my
solution back to the community.


Cheers

Christian
Re: Shortcut for 1:1:n containment reference chains in NodeMapping/ChildReference [message #216968 is a reply to message #216764] Fri, 30 January 2009 15:56 Go to previous messageGo to next message
Alexander Shatalin is currently offline Alexander ShatalinFriend
Messages: 2928
Registered: July 2009
Senior Member
Hello Christian,

> model so that i can ask A for instances of C. (containment, derived,
> transient references from A->C) - Remember: A->B is 1:1 containment
This is a right solution for now with only addition – this reference should
not be containment and GMF should allow you to specify non-containment reference
as containment one in ChildReference (you should be able to igronre warning
on map->gen transformation and generate code then).

> Might it eventually be possible to extend GMF to support this? If so,
I think, generic support of this situation is rather complex, so I doubt
support this kind of “complex diagram structure modelling” will be implemented
in GMF in near future. As you correctly found there is a workaround for this
problem – you can use EMF’s derived features + java to implement all the
logic there so for GMF this will be still a parent domain model element (indirectly)
containing child one..
Nevertheless for now you can try modifying GMF templates (using custom templates
for this diagram editor generation) to handle this situation at least to
some extend. Once you’ll find a solution you can simply raise a bugzilla
request with appropriate patch attached to contribute this functionality
into the project.

First of all you have to modify templates generating CreateCommand to properly
create intermediate element + properly assign child element to the chain
of containment feature. In this case an entry point will be xpt/diagram/commands/CreateNodeCommand.xpt
template.

Then you’ll probably face some problems with update logic. This part will
not be so simple (update is quite compex place in GMF) and in this case you
have to start with xpt/diagram/updater/DiagramUpdater.xpt template.

I can not remember any other templates to be involved into this task, so
good luck and ping me if you get any more questions.

-----------------
Alex Shatalin
Re: Shortcut for 1:1:n containment reference chains in NodeMapping/ChildReference [message #217104 is a reply to message #216968] Tue, 03 February 2009 09:39 Go to previous message
Christian Muth is currently offline Christian MuthFriend
Messages: 24
Registered: July 2009
Junior Member
Hello Alex,


first, let me thank you for your valuable help.

>> model so that i can ask A for instances of C. (containment, derived,
>> transient references from A->C) - Remember: A->B is 1:1 containment
> This is a right solution for now with only addition – this reference
should
> not be containment and GMF should allow you to specify non-containment
reference
> as containment one in ChildReference (you should be able to igronre warning
> on map->gen transformation and generate code then).
I'll soon have a look at the GMF sources to enable selection of
non-containment references. As I can't imagine any other expedient
constraint (than being containment) on the selectable references, I'll
hand it over to the toolsmith to care for the sanity of his/her selection.

>> Might it eventually be possible to extend GMF to support this? If so,
> I think, generic support of this situation is rather complex, so I doubt
> support this kind of “complex diagram structure modelling” will be
implemented
> in GMF in near future. As you correctly found there is a workaround for this
> problem – you can use EMF’s derived features + java to implement all the
> logic there so for GMF this will be still a parent domain model element
(indirectly)
> containing child one..
> Nevertheless for now you can try modifying GMF templates (using custom
templates
> for this diagram editor generation) to handle this situation at least to
> some extend. Once you’ll find a solution you can simply raise a bugzilla
> request with appropriate patch attached to contribute this functionality
> into the project.
Ok, so I'll rather create a plugin extending EMF to be able to create
these "shortcut" references semi-automatically. I agree with you this
being the better way of solving my issues.

> First of all you have to modify templates generating CreateCommand to
properly
> create intermediate element + properly assign child element to the chain
> of containment feature. In this case an entry point will be
xpt/diagram/commands/CreateNodeCommand.xpt
> template.
The child element assignment is no problem at all, I use Feature Seq
Initializers for that which work well.

> Then you’ll probably face some problems with update logic. This part will
> not be so simple (update is quite compex place in GMF) and in this case you
> have to start with xpt/diagram/updater/DiagramUpdater.xpt template.
So far i didn't see any problems with that. Since I delegate all accessor
methods completely to the target class (from A->B->C):
A.getB().getC().getSomeCollection().add(...), C's accessor methods shold
fire notifications properly, do they?

> I can not remember any other templates to be involved into this task, so
> good luck and ping me if you get any more questions.
Thanks a lot, Alex. BTW: Working with GMF is great fun!


Cheers

Christian
Previous Topic:Anyone used Multiple Editors on one model ?
Next Topic:Change decorator being undone
Goto Forum:
  


Current Time: Fri Mar 05 05:32:31 GMT 2021

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

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

Back to the top