Eclipse Community Forums: EMF » Best way to copy element

Help

Home

Home » Modeling » EMF » Best way to copy element

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

Best way to copy element [message #421002]

Mon, 21 July 2008 11:16

Timothy Marc

Messages: 547
Registered: July 2009

Senior Member

Hi all,

i have a sequence diagram for which i had to implement a transformation
programatically. Except for the transformation-speficic adjustments, there
are a lot of elements, which i only want to copy from one resource to the
other. For example:

Every child element of Package org should be moved to Package new in the
other model.

I tried to iterate over the childs and to change their owner, but this
causes me a ConcurrentModificationException. Of course!

My approach was to move all the childs to the new model and then invoke the
Switch-Visitor, what EMF provides, to configure the elements for the new
model (i.e. changing the names, etc.)

It would be great, if someone can give me a hint, how to realize this.

Thx

--Timothy

Report message to a moderator

Re: Best way to copy element [message #421004 is a reply to message #421002]

Mon, 21 July 2008 13:04

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-WzrkolWoJJS9TFysQ+on
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Timothy,

Perhaps you will get better results from actually copying the elements
instead of moving them. The EcoreUtil.copyAll method will copy a bunch
of elements in one operation, including any cross-references between
them (to maintain integrity of the copied graph). You can also
specialize the EcoreUtil.Copier class to customize the algorithm, if
necessary.

Otherwise, perhaps simply copying the eContents() list of an element
before moving it will get you past the ConcurrentModificationException.

HTH,

Christian

On Mon, 2008-07-21 at 13:16 +0200, Timothy Marc wrote:

> Hi all,
>
> i have a sequence diagram for which i had to implement a transformation
> programatically. Except for the transformation-speficic adjustments, there
> are a lot of elements, which i only want to copy from one resource to the
> other. For example:
> copyA
> Every child element of Package org should be moved to Package new in the
> other model.
>
> I tried to iterate over the childs and to change their owner, but this
> causes me a ConcurrentModificationException. Of course!
>
> My approach was to move all the childs to the new model and then invoke the
> Switch-Visitor, what EMF provides, to configure the elements for the new
> model (i.e. changing the names, etc.)
>
> It would be great, if someone can give me a hint, how to realize this.
>
> Thx
>
> --Timothy
>
>

--=-WzrkolWoJJS9TFysQ+on
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Timothy, 
 
Perhaps you will get better results from actually copying the elements instead of moving them.  The EcoreUtil.copyAll method will copy a bunch of elements in one operation, including any cross-references between them (to maintain integrity of the copied graph).  You can also specialize the EcoreUtil.Copier class to customize the algorithm, if necessary. 
 
Otherwise, perhaps simply copying the eContents() list of an element before moving it will get you past the ConcurrentModificationException. 
 
HTH, 
 
Christian 
 
 
On Mon, 2008-07-21 at 13:16 +0200, Timothy Marc wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi all,

i have a sequence diagram for which i had to implement a transformation 
programatically. Except for the transformation-speficic adjustments, there 
are a lot of elements, which i only want to copy from one resource to the 
other. For example:
copyA
Every child element of Package org should be moved to Package new in the 
other model.

I tried to iterate over the childs and to change their owner, but this 
causes me a ConcurrentModificationException. Of course!

My approach was to move all the childs to the new model and then invoke the 
Switch-Visitor, what EMF provides, to configure the elements for the new 
model (i.e. changing the names, etc.)

It would be great, if someone can give me a hint, how to realize this.

Thx

--Timothy 

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-WzrkolWoJJS9TFysQ+on--

Report message to a moderator

Re: Best way to copy element [message #421006 is a reply to message #421004]

Mon, 21 July 2008 13:31

Timothy Marc

Messages: 547
Registered: July 2009

Senior Member

Hey Christian,

thank you fo your rapid answer. Yeah, i found the EcoreUtil-Class in the
minute, i send this post.

But i have a question concerning the Switch mechanism, that is generated
automatically. The switches are packagewide, aren't they? In my containment
tree, i have elements from several packages, and i tried to access the
visitor methods (caseXYZ) like this (taken from the "EMF bible"):

for(final TreeIterator<EObject> it =
pstTestSequences.eAllContents();it.hasNext();){
final EObject element = it.next();
visitor.doSwitch(element);
}

But that works only for the elements, specified in the package which switch
i had extended. I thought that it would be possible to iterate over a whole
containment tree by using a problem-specific specialization of an modelwide
switch. I think this is also the intention from the Visitor pattern, isn't
it? To add additional behavior to a containment/object tree...

May i a have a false imagination of the emf visitor?

Thx
--Timothy

"Christian W. Damus" <cdamus@zeligsoft.com> schrieb im Newsbeitrag
news:1216645450.6639.6.camel@cwdlappy...
Hi, Timothy,

Perhaps you will get better results from actually copying the elements
instead of moving them. The EcoreUtil.copyAll method will copy a bunch of
elements in one operation, including any cross-references between them (to
maintain integrity of the copied graph). You can also specialize the
EcoreUtil.Copier class to customize the algorithm, if necessary.

Otherwise, perhaps simply copying the eContents() list of an element before
moving it will get you past the ConcurrentModificationException.

HTH,

Christian

On Mon, 2008-07-21 at 13:16 +0200, Timothy Marc wrote:
Hi all,

i have a sequence diagram for which i had to implement a transformation
programatically. Except for the transformation-speficic adjustments, there
are a lot of elements, which i only want to copy from one resource to the
other. For example:
copyA
Every child element of Package org should be moved to Package new in the
other model.

I tried to iterate over the childs and to change their owner, but this
causes me a ConcurrentModificationException. Of course!

My approach was to move all the childs to the new model and then invoke the
Switch-Visitor, what EMF provides, to configure the elements for the new
model (i.e. changing the names, etc.)

It would be great, if someone can give me a hint, how to realize this.

Thx

--Timothy

Report message to a moderator

Re: Best way to copy element [message #421009 is a reply to message #421006]

Mon, 21 July 2008 14:22

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-0byNYb/caRfKMcyyVR9d
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Timothy,

For any EPackages that your EPackage extends (by having EClasses that
specialize EClasses from the other packages), your generated Switch will
include cases for the EClasses from those packages that your package
depends on.

For example, the UMLSwitch from the MDT UML2 component
(org.eclipse.uml2.uml) includes a caseEModelElement because uml::Element
specializes ecore::EModelElement.

If this isn't the case, then you can always set up delegation to other
switch instances in your defaultCase. e.g.,

T defaultCase(EObject object) {
Object result;
result = modelASwitch.doSwitch(object);
if (result == null) result = modelBSwitch.doSwitch(object);
if (result == null) result = modelCSwitch.doSwitch(object);
return result;
}

HTH,

Christian

On Mon, 2008-07-21 at 15:31 +0200, Timothy Marc wrote:

> Hey Christian,
>
> thank you fo your rapid answer. Yeah, i found the EcoreUtil-Class in the
> minute, i send this post.
>
> But i have a question concerning the Switch mechanism, that is generated
> automatically. The switches are packagewide, aren't they? In my containment
> tree, i have elements from several packages, and i tried to access the
> visitor methods (caseXYZ) like this (taken from the "EMF bible"):
>
> for(final TreeIterator<EObject> it =
> pstTestSequences.eAllContents();it.hasNext();){
> final EObject element = it.next();
> visitor.doSwitch(element);
> }
>
> But that works only for the elements, specified in the package which switch
> i had extended. I thought that it would be possible to iterate over a whole
> containment tree by using a problem-specific specialization of an modelwide
> switch. I think this is also the intention from the Visitor pattern, isn't
> it? To add additional behavior to a containment/object tree...
>
> May i a have a false imagination of the emf visitor?
>
> Thx
> --Timothy
>
> "Christian W. Damus" <cdamus@zeligsoft.com> schrieb im Newsbeitrag
> news:1216645450.6639.6.camel@cwdlappy...
> Hi, Timothy,
>
> Perhaps you will get better results from actually copying the elements
> instead of moving them. The EcoreUtil.copyAll method will copy a bunch of
> elements in one operation, including any cross-references between them (to
> maintain integrity of the copied graph). You can also specialize the
> EcoreUtil.Copier class to customize the algorithm, if necessary.
>
> Otherwise, perhaps simply copying the eContents() list of an element before
> moving it will get you past the ConcurrentModificationException.
>
> HTH,
>
> Christian
>
>
> On Mon, 2008-07-21 at 13:16 +0200, Timothy Marc wrote:
> Hi all,
>
> i have a sequence diagram for which i had to implement a transformation
> programatically. Except for the transformation-speficic adjustments, there
> are a lot of elements, which i only want to copy from one resource to the
> other. For example:
> copyA
> Every child element of Package org should be moved to Package new in the
> other model.
>
> I tried to iterate over the childs and to change their owner, but this
> causes me a ConcurrentModificationException. Of course!
>
> My approach was to move all the childs to the new model and then invoke the
> Switch-Visitor, what EMF provides, to configure the elements for the new
> model (i.e. changing the names, etc.)
>
> It would be great, if someone can give me a hint, how to realize this.
>
> Thx
>
> --Timothy
>
>

--=-0byNYb/caRfKMcyyVR9d
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Timothy, 
 
For any EPackages that your EPackage extends (by having EClasses that specialize EClasses from the other packages), your generated Switch will include cases for the EClasses from those packages that your package depends on. 
 
For example, the UMLSwitch from the MDT UML2 component (org.eclipse.uml2.uml) includes a caseEModelElement because uml::Element specializes ecore::EModelElement. 
 
If this isn't the case, then you can always set up delegation to other switch instances in your defaultCase.  e.g., 
 
    T defaultCase(EObject object) { 
       Object result; 
       result = modelASwitch.doSwitch(object); 
       if (result == null) result = modelBSwitch.doSwitch(object); 
       if (result == null) result = modelCSwitch.doSwitch(object); 
       return result; 
    } 
 
HTH, 
 
Christian 
 
 
On Mon, 2008-07-21 at 15:31 +0200, Timothy Marc wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hey Christian,

thank you fo your rapid answer. Yeah, i found the EcoreUtil-Class in the 
minute, i send this post.

But i have a question concerning the Switch mechanism, that is generated 
automatically. The switches are packagewide, aren't they? In my containment 
tree, i have elements from several packages, and i tried to access the 
visitor methods (caseXYZ) like this (taken from the "EMF bible"):

for(final TreeIterator<EObject> it = 
pstTestSequences.eAllContents();it.hasNext();){ 
 final EObject element = it.next();
 visitor.doSwitch(element);
}

But that works only for the elements, specified in the package which switch 
i had extended. I thought that it would be possible to iterate over a whole 
containment tree by using a problem-specific specialization of an modelwide 
switch. I think this is also the intention from the Visitor pattern, isn't 
it? To add additional behavior to a containment/object tree...

May i a have a false imagination of the emf visitor?

Thx
--Timothy

"Christian W. Damus" <<A HREF="mailto:cdamus@zeligsoft.com">cdamus@zeligsoft.com</A>> schrieb im Newsbeitrag 
news:1216645450.6639.6.camel@cwdlappy...
Hi, Timothy,

Perhaps you will get better results from actually copying the elements 
instead of moving them. The EcoreUtil.copyAll method will copy a bunch of 
elements in one operation, including any cross-references between them (to 
maintain integrity of the copied graph). You can also specialize the 
EcoreUtil.Copier class to customize the algorithm, if necessary.

Otherwise, perhaps simply copying the eContents() list of an element before 
moving it will get you past the ConcurrentModificationException.

HTH,

Christian

On Mon, 2008-07-21 at 13:16 +0200, Timothy Marc wrote:
Hi all,

i have a sequence diagram for which i had to implement a transformation
programatically. Except for the transformation-speficic adjustments, there
are a lot of elements, which i only want to copy from one resource to the
other. For example:
copyA
Every child element of Package org should be moved to Package new in the
other model.

I tried to iterate over the childs and to change their owner, but this
causes me a ConcurrentModificationException. Of course!

My approach was to move all the childs to the new model and then invoke the
Switch-Visitor, what EMF provides, to configure the elements for the new
model (i.e. changing the names, etc.)

It would be great, if someone can give me a hint, how to realize this.

Thx

--Timothy 

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-0byNYb/caRfKMcyyVR9d--

Report message to a moderator

Previous Topic:	Re: JPA Temporal annotation doesn't work for EReference features
Next Topic:	Resource save performance

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Sep 24 18:35:28 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter