| EcoreUtil.Copier behavior [message #108923] |
Mon, 05 March 2007 11:21  |
Eclipse User |
|
|
|
Originally posted by: kalin.nakov.gmail.com
Hello,
I have a node 'Parent' and a nested node 'Child' inside. When I choose
RightClick->Edit->Duplicate, GMF creates a new object 'Parent' and a
nested child 'Child'. So far so good, but when I try to rename the new
'Child' node, the source 'Child' node gets renamed too. The 'Parent'
node is duplicated correctly.
The reason for that is that the EMF objects inside the containment
relationships are not duplicated, but just copied as references. I want
to implement my own copier that iterates through the containment
relationships and for each references there first to remove them, then
to duplicate them recursively and finally add them back. I think this is
basic functionality so I believe there is already something invented.
Is there a Copier that fulfills my needs?
Thanks,
Kalin
|
|
|
| Re: EcoreUtil.Copier behavior [message #108978 is a reply to message #108923] |
Mon, 05 March 2007 13:19  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Kalin Nakov wrote:
> Hello,
>
> I have a node 'Parent' and a nested node 'Child' inside. When I choose
> RightClick->Edit->Duplicate, GMF creates a new object 'Parent' and a
> nested child 'Child'. So far so good, but when I try to rename the new
> 'Child' node, the source 'Child' node gets renamed too. The 'Parent'
> node is duplicated correctly.
>
> The reason for that is that the EMF objects inside the containment
> relationships are not duplicated, but just copied as references.
Are you sure. Certainly EcoreUtil.copier doesn't do that, it copies the
full depth of the containment tree. Furthermore, if the children
weren't copied but were reused in the copied parent, they would removed
from the original parent.
> I want to implement my own copier that iterates through the
> containment relationships and for each references there first to
> remove them, then to duplicate them recursively and finally add them
> back.
I don't understand why removal is necessary.
> I think this is basic functionality so I believe there is already
> something invented. Is there a Copier that fulfills my needs?
It sounds more like your Parent/Child reference is not a containment.
>
> Thanks,
> Kalin
|
|
|
|
| Re: EcoreUtil.Copier behavior [message #109162 is a reply to message #108978] |
Tue, 06 March 2007 04:30 |
| Eclipse User |
|
|
|
Originally posted by: kalin.nakov.gmail.com
I just want to implement a working duplicate command. The current
implementation of DuplicateEObjectsCommand duplicates the root element,
but all its children are not duplicated - they are duplicated visually
in the diagram, but are not duplicated semantically in the domain model.
I use GMFResourceFactory to create my resources.
Ed Merks wrote:
> Kalin Nakov wrote:
>> Hello,
>>
>> I have a node 'Parent' and a nested node 'Child' inside. When I choose
>> RightClick->Edit->Duplicate, GMF creates a new object 'Parent' and a
>> nested child 'Child'. So far so good, but when I try to rename the new
>> 'Child' node, the source 'Child' node gets renamed too. The 'Parent'
>> node is duplicated correctly.
>>
>> The reason for that is that the EMF objects inside the containment
>> relationships are not duplicated, but just copied as references.
> Are you sure. Certainly EcoreUtil.copier doesn't do that, it copies the
> full depth of the containment tree. Furthermore, if the children
> weren't copied but were reused in the copied parent, they would removed
> from the original parent.
>> I want to implement my own copier that iterates through the
>> containment relationships and for each references there first to
>> remove them, then to duplicate them recursively and finally add them
>> back.
> I don't understand why removal is necessary.
>> I think this is basic functionality so I believe there is already
>> something invented. Is there a Copier that fulfills my needs?
> It sounds more like your Parent/Child reference is not a containment.
>>
>> Thanks,
>> Kalin
I
|
|
|
| Re: EcoreUtil.Copier behavior [message #109226 is a reply to message #109162] |
Tue, 06 March 2007 09:11 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Kalin,
I don't know much about this command, but glancing at it, I get the
impression that you should pass to it the complete list of all the
objects you want duplicated, not just the root of a tree. You can use
EObject.eAllContents() to iterate over all the contained children and
add those to the list.
Kalin Nakov wrote:
> I just want to implement a working duplicate command. The current
> implementation of DuplicateEObjectsCommand duplicates the root
> element, but all its children are not duplicated - they are duplicated
> visually in the diagram, but are not duplicated semantically in the
> domain model. I use GMFResourceFactory to create my resources.
>
> Ed Merks wrote:
>> Kalin Nakov wrote:
>>> Hello,
>>>
>>> I have a node 'Parent' and a nested node 'Child' inside. When I
>>> choose RightClick->Edit->Duplicate, GMF creates a new object
>>> 'Parent' and a nested child 'Child'. So far so good, but when I try
>>> to rename the new 'Child' node, the source 'Child' node gets renamed
>>> too. The 'Parent' node is duplicated correctly.
>>>
>>> The reason for that is that the EMF objects inside the containment
>>> relationships are not duplicated, but just copied as references.
>> Are you sure. Certainly EcoreUtil.copier doesn't do that, it copies
>> the full depth of the containment tree. Furthermore, if the children
>> weren't copied but were reused in the copied parent, they would
>> removed from the original parent.
>>> I want to implement my own copier that iterates through the
>>> containment relationships and for each references there first to
>>> remove them, then to duplicate them recursively and finally add them
>>> back.
>> I don't understand why removal is necessary.
>>> I think this is basic functionality so I believe there is already
>>> something invented. Is there a Copier that fulfills my needs?
>> It sounds more like your Parent/Child reference is not a containment.
>>>
>>> Thanks,
>>> Kalin
> I
|
|
|
| Re: EcoreUtil.Copier behavior [message #109340 is a reply to message #108923] |
Tue, 06 March 2007 11:45 |
| Eclipse User |
|
|
|
> I have a node 'Parent' and a nested node 'Child' inside. When I choose
> RightClick->Edit->Duplicate, GMF creates a new object 'Parent' and a
> nested child 'Child'. So far so good, but when I try to rename the new
> 'Child' node, the source 'Child' node gets renamed too. The 'Parent'
> node is duplicated correctly.
I just checked: uml2tools have the same issue. If I use the duplicate
command on a class with ports, I get a new class with a new xmi:id value
and everything is fine in the ecore file, but the ports of the
duplicated class in the diagram file reference/use the same xmi:id value
as the original ports.
So if I change the label of a port in the original class after the
duplicate, this change is applied to the duplicated class in the diagram
but not the new port of that class in the ecore file - thus creating a
real inconsistency.
Armin
|
|
|
Powered by
FUDForum. Page generated in 0.04904 seconds
Home