| Shortcut for 1:1:n containment reference chains in NodeMapping/ChildReference [message #216764] |
Thu, 29 January 2009 19:01  |
 Christian Muth
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 #217104 is a reply to message #216968] |
Tue, 03 February 2009 09:39  |
Christian Muth
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
|
|
|
Powered by
FUDForum. Page generated in 0.03519 seconds
] 
Search
Help
Register
Login
Home
