Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » EMF.Edit: Deleting non-containment tree items deletes all references

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » EMF.Edit: Deleting non-containment tree items deletes all references

Show: Today's Messages :: Show Polls :: Message Navigator

EMF.Edit: Deleting non-containment tree items deletes all references [message #735672]

Wed, 12 October 2011 14:14

pro.kyon

Messages: 6
Registered: October 2011

Junior Member

Hi all,

I've generated the basic tree editor that comes with EMF.
The problem is, that deleting element references from the referencing model (via the context menu delete action) also deletes the elements from the referenced model.

Here's what the tree editor looks like:

Model A:

- Node
    - Elem1 (non-containment ref)
    - Elem2 (non-containment ref)
    - Elem3 (non-containment ref)

Model B:

- ElemContainer1
    - Elem1 (actual referenced element, containment)
    - Elem2 (actual referenced element, containment)
- ElemContainer2
    - Elem3 (actual referenced element, containment)

As you can see, Model A references Model B. Elem1-3 are modeled as a reference feature, with the "Containment" flag set to true, but the "Children"-flag in the genmodel is set to "True", in order to display those as individual tree items.
If I delete the nodes in Model A, they are also deleted in Model B. What I actually intend is to remove them only from the corresponding feature of "Node" in Model A.

I have already come across the EditingDomainActionBarContributor and its "removeAllReferencesOnDelete()". Unfortunately returning "false" in that method only deletes the elements from the referenced model, which is exactly the opposite of what I need.

Did anyone else ever run into that problem? Any help is greatly appreciated.

Edit: Thinking about it now, there might be another solution. I could create a new Type "ElemRef" with a 0..1 reference-feature and make the original feature a containment.
Anyways, I'd still like to now if the described behavior is intended and if my solution is indeed the best way to go.

Regards

[Updated on: Wed, 12 October 2011 14:16]

Report message to a moderator

Re: EMF.Edit: Deleting non-containment tree items deletes all references [message #735736 is a reply to message #735672]

Wed, 12 October 2011 15:49

Ed Merks

Messages: 33140
Registered: July 2009

Senior Member

Comments below.

On 12/10/2011 4:14 PM, pro.kyon wrote:
> Hi all,
>
> I've generated the basic tree editor that comes with EMF.
> The problem is, that deleting element references from the referencing
> model (via the context menu delete action) also deletes the elements
> from the referenced model.
>
> Here's what the tree editor look like:
>
> Model A:
>
> - Node
You need to ensure you're using wrappers if you have non-containment
references as children and show these nodes elsewhere. Specialize
isWrappingNeeded to return true for NodeItemProviderAdapter.
> - Elem1 (non-containment ref)
> - Elem2 (non-containment ref)
> - Elem3 (non-containment ref)
>
> Model B:
>
> - ElemContainer1
> - Elem1 (actual referenced element, containment)
> - Elem2 (actual referenced element, containment)
> - ElemContainer2
> - Elem3 (actual referenced element, containment)
>
>
> As you can see, Model A references Model B. Elem1-3 are modeled as a
> reference feature, with the "Containment" flag set to true, but the
> "Children"-flag in the genmodel is set to "True", in order to display
> those as individual tree items.
> If I delete the nodes in Model A, they are also deleted in Model B.
> What I actually intend is to remove them only from the corresponding
> feature of "Node" in Model A.
>
> I have already come across the EditingDomainActionBarContributor and
> its "removeAllReferencesOnDelete()". Unfortunately returning "false"
> in that method only deletes the elements from the referenced model,
> which is exactly the opposite of what I need.
>
> Did anyone else ever run into that problem. Any help is greatly
> appreciated.
>
> Edit: Thinking about it now, there might be another solution. I could
> create a new Type "ElemRef" with a 0..1 reference-feature and make
> the original feature a containment.
> Anyways, I'd still like to now if the described behavior is intended
> and if my solution is indeed the best way to go.
>
> Regards
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator