| Click on one, insert in another [message #57002] |
Thu, 28 September 2006 11:13  |
Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Hello,
is there a way to have a newly created item inserted in a different element
than the one the user clicked on? I tried out the children-feature, but I
do not get any features of this element's childs...
Here are the two situations. I'll model the containment structure and
annotate what item has to be clicked on and where the new item shall be
inserted.
a)
Subprocess <- click here
+-EmbeddedSubprocessAttributeSet
+-GraphicalElements <- insert here
b)
Pool
+-Process (unique)
+-GraphicalElements <- insert here
+-Lane <-click here
Tobias
|
|
|
|
| Re: Click on one, insert in another [message #57452 is a reply to message #57239] |
Fri, 29 September 2006 11:47  |
| Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Artem Tikhomirov wrote:
> You'll need to modify creation command, gmfmap's children feature is not
> for that usecase.
>
> Artem
Ok, so I'd have to create a pseudo-containment-feature for the Class I want
to click on, so the right editParts and polcies are created. Later, the
pseudo-containment-feature would has to be removed again (or just ignored).
I took a look at the CompartmentItemSemanticEditPolicy. There a constant is
used to specify where to put stuff in (similar to the gmpmap). I doubt that
I can What method do I have to override to specify where to put it, when it
is not a feature of the class itself [1]? Execute? And could you point out
or send me a reference where else I would have to make changes, like for
moving or deleting the created element?
Thanks,
Tobias
[1] As I said: I want to click on a "Lane" and insert the new Element in the
collection Lane.getParentPool().getProcess().getGraphicalElements()
|
|
|
| Re: Click on one, insert in another [message #57531 is a reply to message #57452] |
Fri, 29 September 2006 12:51 |
 Artem Tikhomirov
Messages: 222
Registered: July 2009 |
Senior Member |
|
|
Right, XXXItemSemanticEditPolicy is the place to fix.
1. req.setContainmentFeature() is self-description. put correct metafeature
here (Pool_Process i suspect)
2. CreateXXXCommand - modify getEClassToEdit to point to owner of
containment feature from (1).
3. Fix getElementToEdit() method - navigate to the appropriate element (e.g.
Lane.getParentPool())
These midifications control only changes in the domain model, placement of
grapical elements should happen according to addChildVisual() logic in
appropriate edit parts.
As for move and delete, there should be no additional efforts (container
element is known at the time of removal)
Artem
"tobias" <tobk@gmx.de> wrote in message
news:efj12h$blm$1@utils.eclipse.org...
> Artem Tikhomirov wrote:
>
>> You'll need to modify creation command, gmfmap's children feature is not
>> for that usecase.
>>
>> Artem
>
> Ok, so I'd have to create a pseudo-containment-feature for the Class I
> want
> to click on, so the right editParts and polcies are created. Later, the
> pseudo-containment-feature would has to be removed again (or just
> ignored).
>
> I took a look at the CompartmentItemSemanticEditPolicy. There a constant
> is
> used to specify where to put stuff in (similar to the gmpmap). I doubt
> that
> I can What method do I have to override to specify where to put it, when
> it
> is not a feature of the class itself [1]? Execute? And could you point out
> or send me a reference where else I would have to make changes, like for
> moving or deleting the created element?
>
> Thanks,
> Tobias
>
> [1] As I said: I want to click on a "Lane" and insert the new Element in
> the
> collection Lane.getParentPool().getProcess().getGraphicalElements()
|
|
|
| Re: Click on one, insert in another [message #57726 is a reply to message #57531] |
Fri, 29 September 2006 20:52 |
| Eclipse User |
|
|
|
Originally posted by: tobk.gmx.de
Artem Tikhomirov wrote:
> Right, XXXItemSemanticEditPolicy is the place to fix.
> 1. req.setContainmentFeature() is self-description. put correct
> metafeature here (Pool_Process i suspect)
> 2. CreateXXXCommand - modify getEClassToEdit to point to owner of
> containment feature from (1).
> 3. Fix getElementToEdit() method - navigate to the appropriate element
> (e.g. Lane.getParentPool())
>
> These midifications control only changes in the domain model, placement of
> grapical elements should happen according to addChildVisual() logic in
> appropriate edit parts.
>
> As for move and delete, there should be no additional efforts (container
> element is known at the time of removal)
>
> Artem
Thanks, it works well for creation and delition, but when I move an element
it is reinserted in the pseudoElements-Feature (which is bad...). I think
I'll just keep my eyes open for occurances of the pseudoElements-Feature
and sooner or later I'll find the place to edit - but if anyone already
knows, please tell me! *g*
tobias
By the way, I mentioned a kinda strange behaviour of the generator: Most of
my elements can be inserted in two containers, which, as we all know,
results in duplicate EditParts for these features. However, when I
generated the editor with the ChildReferences contained in the second
container while the original EditParts already existed the duplicates where
not generated. When I deleted and recreated the whole editor (to get rid of
junk code from former configurations) the duplicates where there again.
So maybe you can generally avoid the duplicates by creating the editor with
only the originals in the gmfmap, then pasting the reference-children in
the map and recreating the code.
|
|
|
Powered by
FUDForum. Page generated in 0.04095 seconds
] 
Search
Help
Register
Login
Home
