Home » Modeling » EMF » Overriding InitializeCopyCommand to increment ID
| |
| Re: Overriding InitializeCopyCommand to increment ID [message #428989 is a reply to message #428973] |
Mon, 06 April 2009 14:43   |
 Michael Mühlberg
Messages: 33
Registered: July 2009 |
Member |
|
|
I also have that problem with unique identifiers and the fact that the Ecore
copy function is not aware of them.
Wouldn't it be a good idea for the Ecore copy function to provide an
(optional) call back mechanism for all attributes with iD=true into the
caller of the copy function so that the ID can be changed for the copy? I
mean, an ID is an ID, and it should identify one single object uniquely,
shouldn't it?
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:grco27$uhb$1@build.eclipse.org...
> Stephen,
>
> You might well create copies but then not actually end up using them, as
> you've found out. Perhaps the override should be in the add/set command
> that actually attaches the object to a container that's part of the
> resource, though I suppose that gets tricky as you start to copy deeper
> tree structures. Managing ID uniqueness is a tricky problem in general.
> After all, are you checking that nothing has already used the incremented
> ID? Perhaps rather than a counter you should scan the resource to use the
> next available unique ID.
>
>
> Stephen Egan wrote:
>> Hi,
>>
>> I need to override the default functionality of the InitializeCopyCommand
>> so as to increment objects' unique ID attribute. I have overriden the
>> doExecute() method to perform this action. All works well if I copy and
>> paste within my editor (TreeViewer) using the menu or keyboard shortcuts.
>> However, if I try to copy using Drag and Drop while holding down the CTRL
>> key, the doExecute() method gets called repeatedly until I release the
>> mouse button - incrementing my ID counter each time.
>>
>> Presumably I'm incrementing my ID in the wrong place, but am having
>> difficulty finding out where to do this so that it is only called when
>> the copy of the object is actually added to the model while using Drag
>> and Drop. Any help would be greatly appreciated.
>>
>> //Stephen Egan
>>
>>
|
|
| |
| Re: Overriding InitializeCopyCommand to increment ID [message #429036 is a reply to message #428994] |
Tue, 07 April 2009 05:33 |
Stephen Egan
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
Thanks for your suggestion - that set me off on the right path. In the
end, I have overriden the createAddCommand() method in my ItemProvider to
create a CompoundCommand. I then append the result of
super.createAddCommand() and a series of SetCommands for setting my ID
attribute for each affected object. Finally I append another SetCommand
to store the last used ID number in my top level object - this is
sufficient for me to keep track of IDs.
This is working almost exactly as I would like it to. Copy and paste via
keyboard, menus or drag and drop work as I would expect it. Additionally,
if I simply move an object (using drag and drop) from one container to
another, the existing ID is preserved. This is done by checking if the
EObject already has an eContainer. The only remaining problem I have is
when I cut and paste. I consider this conceptually the same as moving an
object, and thus would like to preserve the existing ID. However, it
seems that the "cut" action results in the object's eContainer being
removed, so my existing methodology doesn't work. This will require a bit
more thinking to resolve.
Code snippet from my ItemProvider class below:
All the best to you and yours,
Stephen.
@Override
protected Command createAddCommand(EditingDomain domain, EObject owner,
EStructuralFeature feature, Collection<?> collection, int index) {
// Get the AddCommand from the super class implementation
Command cmd = super.createAddCommand(domain, owner, feature,
collection, index);
// Create a CompooundCommand to contain all the Commands created here.
CompoundCommand ret = new CompoundCommand();
// Append the AddCommand from the super class
ret.append(cmd);
// Get my top level object where ID numbers are tracked
ProjectType pt = getProjectType(domain);
// Get the last used ID number
BigInteger bocode = pt.getGbLastCode();
logger.info("Last used bocode = "
+ (bocode == null ? "null" : bocode.toString()));
BigInteger newBoCode = bocode;
// Check for, and address nulls from legacy models
if (newBoCode == null)
newBoCode = BigInteger.ZERO;
// Iterate over each object being added
for (Iterator iterator = collection.iterator(); iterator.hasNext();) {
Object value = (Object) iterator.next();
logger.info("Value Object is " + value.toString());
// ZoneType is what I'm interested in for this case
if (value instanceof ZoneType) {
ZoneType zone = (ZoneType) value;
EObject container = zone.eContainer();
// Check if there is already an eContainer for this EObject
if (container != null) {
// Preserve existing bocode (ID)
logger.info("Container is not null: "
+ container.toString());
} else {
// need a new bocode (ID)
logger.info("Container is null");
newBoCode = newBoCode.add(BigInteger.ONE);
// Create a new SetCommand for adding the bocode (ID) and
// append to the CompoundCommand
Command cmd3 = SetCommand.create(domain, zone,
AccuRateDerivedPackage.eINSTANCE
.getZoneType_BoCode(), newBoCode);
ret.append(cmd3);
}
}
}
// Check that the ID counter has changed
if (newBoCode != bocode) {
// Create a new SetCommand to write back the last ID used to my top
// level object, and append to the COmpoundCommand
Command cmd2 = SetCommand.create(domain, pt,
AccuRateDerivedPackage.eINSTANCE
.getProjectType_GbLastCode(), newBoCode);
ret.append(cmd2);
}
// Return my CompoundCommand.
return ret;
}
On Tue, 07 Apr 2009 01:02:02 +1000, Ed Merks <Ed.Merks@gmail.com> wrote:
> Michael,
>
> Comments below.
>
> Michael Mühlberg wrote:
>> I also have that problem with unique identifiers and the fact that the
>> Ecore
>> copy function is not aware of them.
>>
> It's making a copy and that will include copying every feature, whether
> or not its an ID. After all, you might want to create a copy you can
> put into a different resource and would like the IDs to be the same as
> before.
>> Wouldn't it be a good idea for the Ecore copy function to provide an
>> (optional) call back mechanism for all attributes with iD=true into the
>> caller of the copy function so that the ID can be changed for the copy?
> You can specialize the Copier itself, i.e., copyAttribute.
>> I
>> mean, an ID is an ID, and it should identify one single object uniquely,
>> shouldn't it?
>>
> It's not a UUID. It's not required to be universally unique, only
> unique within a resource and who's to say what you're going to do with
> your copy and who's to say how best to create a new ID that will be
> unique in whatever context you plan to use the copy...
>> Ciao, Michael
>>
>>
>>
>>
>> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
>> news:grco27$uhb$1@build.eclipse.org...
>>
>>> Stephen,
>>>
>>> You might well create copies but then not actually end up using them,
>>> as
>>> you've found out. Perhaps the override should be in the add/set
>>> command
>>> that actually attaches the object to a container that's part of the
>>> resource, though I suppose that gets tricky as you start to copy deeper
>>> tree structures. Managing ID uniqueness is a tricky problem in
>>> general.
>>> After all, are you checking that nothing has already used the
>>> incremented
>>> ID? Perhaps rather than a counter you should scan the resource to use
>>> the
>>> next available unique ID.
>>>
>>>
>>> Stephen Egan wrote:
>>>
>>>> Hi,
>>>>
>>>> I need to override the default functionality of the
>>>> InitializeCopyCommand
>>>> so as to increment objects' unique ID attribute. I have overriden the
>>>> doExecute() method to perform this action. All works well if I copy
>>>> and
>>>> paste within my editor (TreeViewer) using the menu or keyboard
>>>> shortcuts.
>>>> However, if I try to copy using Drag and Drop while holding down the
>>>> CTRL
>>>> key, the doExecute() method gets called repeatedly until I release the
>>>> mouse button - incrementing my ID counter each time.
>>>>
>>>> Presumably I'm incrementing my ID in the wrong place, but am having
>>>> difficulty finding out where to do this so that it is only called when
>>>> the copy of the object is actually added to the model while using Drag
>>>> and Drop. Any help would be greatly appreciated.
>>>>
>>>> //Stephen Egan
>>>>
>>>>
>>>>
>>
>>
>>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Overriding InitializeCopyCommand to increment ID [message #429042 is a reply to message #429036] |
Tue, 07 April 2009 05:50 |
Stephen Egan
Messages: 21
Registered: July 2009 |
Junior Member |
|
|
Just a follow up. I have addressed the Cut and Paste issue by overriding
the createRemoveCommand() method in my ItemProvider to add Objects removed
to a java.util.Set. I then check that Set in the createAddCommand()
mentioned below. If it is present, I do not change the ID attribute.
This seems to work as I expect it to, however, I suspect this fix may
cause me some trouble down the line someday.
//Stephen
On Tue, 07 Apr 2009 15:33:21 +1000, Stephen Egan <Stephen.Egan@csiro.au>
wrote:
> Hi Ed,
>
> Thanks for your suggestion - that set me off on the right path. In the
> end, I have overriden the createAddCommand() method in my ItemProvider
> to create a CompoundCommand. I then append the result of
> super.createAddCommand() and a series of SetCommands for setting my ID
> attribute for each affected object. Finally I append another SetCommand
> to store the last used ID number in my top level object - this is
> sufficient for me to keep track of IDs.
>
> This is working almost exactly as I would like it to. Copy and paste
> via keyboard, menus or drag and drop work as I would expect it.
> Additionally, if I simply move an object (using drag and drop) from one
> container to another, the existing ID is preserved. This is done by
> checking if the EObject already has an eContainer. The only remaining
> problem I have is when I cut and paste. I consider this conceptually
> the same as moving an object, and thus would like to preserve the
> existing ID. However, it seems that the "cut" action results in the
> object's eContainer being removed, so my existing methodology doesn't
> work. This will require a bit more thinking to resolve.
>
> Code snippet from my ItemProvider class below:
>
> All the best to you and yours,
>
> Stephen.
>
> @Override
> protected Command createAddCommand(EditingDomain domain, EObject owner,
> EStructuralFeature feature, Collection<?> collection, int index) {
> // Get the AddCommand from the super class implementation
> Command cmd = super.createAddCommand(domain, owner, feature,
> collection, index);
>
> // Create a CompooundCommand to contain all the Commands created here.
> CompoundCommand ret = new CompoundCommand();
>
> // Append the AddCommand from the super class
> ret.append(cmd);
>
> // Get my top level object where ID numbers are tracked
> ProjectType pt = getProjectType(domain);
> // Get the last used ID number
> BigInteger bocode = pt.getGbLastCode();
> logger.info("Last used bocode = "
> + (bocode == null ? "null" : bocode.toString()));
> BigInteger newBoCode = bocode;
> // Check for, and address nulls from legacy models
> if (newBoCode == null)
> newBoCode = BigInteger.ZERO;
> // Iterate over each object being added
> for (Iterator iterator = collection.iterator(); iterator.hasNext();) {
> Object value = (Object) iterator.next();
> logger.info("Value Object is " + value.toString());
>
> // ZoneType is what I'm interested in for this case
> if (value instanceof ZoneType) {
> ZoneType zone = (ZoneType) value;
> EObject container = zone.eContainer();
> // Check if there is already an eContainer for this EObject
> if (container != null) {
> // Preserve existing bocode (ID)
> logger.info("Container is not null: "
> + container.toString());
> } else {
> // need a new bocode (ID)
> logger.info("Container is null");
> newBoCode = newBoCode.add(BigInteger.ONE);
> // Create a new SetCommand for adding the bocode (ID) and
> // append to the CompoundCommand
> Command cmd3 = SetCommand.create(domain, zone,
> AccuRateDerivedPackage.eINSTANCE
> .getZoneType_BoCode(), newBoCode);
> ret.append(cmd3);
>
> }
> }
> }
> // Check that the ID counter has changed
> if (newBoCode != bocode) {
> // Create a new SetCommand to write back the last ID used to my top
> // level object, and append to the COmpoundCommand
> Command cmd2 = SetCommand.create(domain, pt,
> AccuRateDerivedPackage.eINSTANCE
> .getProjectType_GbLastCode(), newBoCode);
> ret.append(cmd2);
> }
>
> // Return my CompoundCommand.
> return ret;
> }
>
> On Tue, 07 Apr 2009 01:02:02 +1000, Ed Merks <Ed.Merks@gmail.com> wrote:
>
>> Michael,
>>
>> Comments below.
>>
>> Michael Mühlberg wrote:
>>> I also have that problem with unique identifiers and the fact that the
>>> Ecore
>>> copy function is not aware of them.
>>>
>> It's making a copy and that will include copying every feature, whether
>> or not its an ID. After all, you might want to create a copy you can
>> put into a different resource and would like the IDs to be the same as
>> before.
>>> Wouldn't it be a good idea for the Ecore copy function to provide an
>>> (optional) call back mechanism for all attributes with iD=true into the
>>> caller of the copy function so that the ID can be changed for the copy?
>> You can specialize the Copier itself, i.e., copyAttribute.
>>> I
>>> mean, an ID is an ID, and it should identify one single object
>>> uniquely,
>>> shouldn't it?
>>>
>> It's not a UUID. It's not required to be universally unique, only
>> unique within a resource and who's to say what you're going to do with
>> your copy and who's to say how best to create a new ID that will be
>> unique in whatever context you plan to use the copy...
>>> Ciao, Michael
>>>
>>>
>>>
>>>
>>> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
>>> news:grco27$uhb$1@build.eclipse.org...
>>>
>>>> Stephen,
>>>>
>>>> You might well create copies but then not actually end up using them,
>>>> as
>>>> you've found out. Perhaps the override should be in the add/set
>>>> command
>>>> that actually attaches the object to a container that's part of the
>>>> resource, though I suppose that gets tricky as you start to copy
>>>> deeper
>>>> tree structures. Managing ID uniqueness is a tricky problem in
>>>> general.
>>>> After all, are you checking that nothing has already used the
>>>> incremented
>>>> ID? Perhaps rather than a counter you should scan the resource to
>>>> use the
>>>> next available unique ID.
>>>>
>>>>
>>>> Stephen Egan wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I need to override the default functionality of the
>>>>> InitializeCopyCommand
>>>>> so as to increment objects' unique ID attribute. I have overriden
>>>>> the
>>>>> doExecute() method to perform this action. All works well if I copy
>>>>> and
>>>>> paste within my editor (TreeViewer) using the menu or keyboard
>>>>> shortcuts.
>>>>> However, if I try to copy using Drag and Drop while holding down the
>>>>> CTRL
>>>>> key, the doExecute() method gets called repeatedly until I release
>>>>> the
>>>>> mouse button - incrementing my ID counter each time.
>>>>>
>>>>> Presumably I'm incrementing my ID in the wrong place, but am having
>>>>> difficulty finding out where to do this so that it is only called
>>>>> when
>>>>> the copy of the object is actually added to the model while using
>>>>> Drag
>>>>> and Drop. Any help would be greatly appreciated.
>>>>>
>>>>> //Stephen Egan
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Overriding InitializeCopyCommand to increment ID [message #429074 is a reply to message #428994] |
Tue, 07 April 2009 14:19 |
Michael Mühlberg
Messages: 33
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0073_01C9B79C.97F2E930
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Ed,
yes, you are completely right.
I meant an OPTIONAL possibility to change an iD-tagged attribute, the =
default case should be like today. I only felt that the attribute-iD =
concept could also be used by the Ecore copier, only an idea, nothing =
else...
The thing with the override functionality gets problematic where =
metamodel federation is in the game. Imagine that someone creates a =
basic metamodel that gets used by other higher level metamodels, and you =
even don't know who is using your basic metamodel. But your basic =
metamodel has an ID in it that can only be copied by your adapted =
copier. Then every higher metamodel developer is forced to use only your =
adapted copier, he or she can not use the EcoreUtil one. And even worse, =
it can be that this problem is not covered during the development =
process, but later at the customer side.
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:grd5hd$dp4$1@build.eclipse.org...
Michael,
Comments below.
Michael M=FChlberg wrote:=20
I also have that problem with unique identifiers and the fact that the =
Ecore=20
copy function is not aware of them.
It's making a copy and that will include copying every feature, =
whether or not its an ID. After all, you might want to create a copy =
you can put into a different resource and would like the IDs to be the =
same as before.
Wouldn't it be a good idea for the Ecore copy function to provide an=20
(optional) call back mechanism for all attributes with iD=3Dtrue into =
the=20
caller of the copy function so that the ID can be changed for the copy? =
You can specialize the Copier itself, i.e., copyAttribute.
I=20
mean, an ID is an ID, and it should identify one single object uniquely, =
shouldn't it?
It's not a UUID. It's not required to be universally unique, only =
unique within a resource and who's to say what you're going to do with =
your copy and who's to say how best to create a new ID that will be =
unique in whatever context you plan to use the copy...
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message=20
news:grco27$uhb$1@build.eclipse.org...
Stephen,
You might well create copies but then not actually end up using them, as =
you've found out. Perhaps the override should be in the add/set =
command=20
that actually attaches the object to a container that's part of the=20
resource, though I suppose that gets tricky as you start to copy deeper=20
tree structures. Managing ID uniqueness is a tricky problem in general. =
After all, are you checking that nothing has already used the =
incremented=20
ID? Perhaps rather than a counter you should scan the resource to use =
the=20
next available unique ID.
Stephen Egan wrote:
Hi,
I need to override the default functionality of the =
InitializeCopyCommand=20
so as to increment objects' unique ID attribute. I have overriden the=20
doExecute() method to perform this action. All works well if I copy and =
paste within my editor (TreeViewer) using the menu or keyboard =
shortcuts.=20
However, if I try to copy using Drag and Drop while holding down the =
CTRL=20
key, the doExecute() method gets called repeatedly until I release the=20
mouse button - incrementing my ID counter each time.
Presumably I'm incrementing my ID in the wrong place, but am having=20
difficulty finding out where to do this so that it is only called when=20
the copy of the object is actually added to the model while using Drag=20
and Drop. Any help would be greatly appreciated.
//Stephen Egan
=20
------=_NextPart_000_0073_01C9B79C.97F2E930
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3Dtext/html;charset=3DISO-8859-1 =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff text=3D#000000>
<DIV><FONT size=3D2 face=3DArial>Hello Ed,</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>yes, you are completely =
right.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>I meant an OPTIONAL possibility to =
change an=20
iD-tagged attribute, the default case should be like today. I only felt =
that the=20
attribute-iD concept could also be used by the Ecore copier, only an =
idea,=20
nothing else...</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>The thing with the override =
functionality gets=20
problematic where metamodel federation is in the game. Imagine that =
someone=20
creates a basic metamodel that gets used by other higher level =
metamodels, and=20
you even don't know who is using your basic metamodel. But your basic =
metamodel=20
has an ID in it that can only be copied by your adapted copier. Then =
every=20
higher metamodel developer is forced to use only your adapted copier, he =
or she=20
can not use the EcoreUtil one. And even worse, it can be that this =
problem is=20
not covered during the development process, but later at the customer=20
side.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>Ciao, Michael</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:grd5hd$dp4$1@build.eclipse.org">news:grd5hd$dp4$1@build.ecli=
pse.org</A>...</DIV>Michael,<BR><BR>Comments=20
below.<BR><BR>Michael M=FChlberg wrote:=20
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">I also have that problem with unique =
identifiers and the fact that the Ecore=20
copy function is not aware of them.
</PRE></BLOCKQUOTE>It's making a copy and that will include copying =
every=20
feature, whether or not its an ID. After all, you might want to =
create a=20
copy you can put into a different resource and would like the IDs to =
be the=20
same as before.<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Wouldn't it be a good idea for the Ecore =
copy function to provide an=20
(optional) call back mechanism for all attributes with iD=3Dtrue into =
the=20
caller of the copy function so that the ID can be changed for the copy? =
</PRE></BLOCKQUOTE>You=20
can specialize the Copier itself, i.e., copyAttribute.<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">I=20
mean, an ID is an ID, and it should identify one single object uniquely, =
shouldn't it?
</PRE></BLOCKQUOTE>It's not a UUID. It's not required to be=20
universally unique, only unique within a resource and who's to say =
what you're=20
going to do with your copy and who's to say how best to create a new =
ID that=20
will be unique in whatever context you plan to use the copy...<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Ciao, Michael
"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:Ed.Merks@gmail.com"><Ed.Merks@gmail.com></A> wrote =
in message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:grco27$uhb$1@build.eclipse.org">news:grco27$uhb$1@build.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Stephen,
You might well create copies but then not actually end up using them, as =
you've found out. Perhaps the override should be in the add/set =
command=20
that actually attaches the object to a container that's part of the=20
resource, though I suppose that gets tricky as you start to copy deeper=20
tree structures. Managing ID uniqueness is a tricky problem in general. =
After all, are you checking that nothing has already used the =
incremented=20
ID? Perhaps rather than a counter you should scan the resource to use =
the=20
next available unique ID.
Stephen Egan wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi,
I need to override the default functionality of the =
InitializeCopyCommand=20
so as to increment objects' unique ID attribute. I have overriden the=20
doExecute() method to perform this action. All works well if I copy and =
paste within my editor (TreeViewer) using the menu or keyboard =
shortcuts.=20
However, if I try to copy using Drag and Drop while holding down the =
CTRL=20
key, the doExecute() method gets called repeatedly until I release the=20
mouse button - incrementing my ID counter each time.
Presumably I'm incrementing my ID in the wrong place, but am having=20
difficulty finding out where to do this so that it is only called when=20
the copy of the object is actually added to the model while using Drag=20
and Drop. Any help would be greatly appreciated.
//Stephen Egan
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->
</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0073_01C9B79C.97F2E930--
|
|
| |
| Re: Overriding InitializeCopyCommand to increment ID [message #429095 is a reply to message #429076] |
Wed, 08 April 2009 07:14 |
Michael Mühlberg
Messages: 33
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0019_01C9B82A.7ABBB930
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Ed,
in my opinion implementing the "one right way" is not necessary, just =
"two right ways" are going to be implemented :)
In this special case it would be sufficient to provide an additional =
second copy method in EcoreUtil, that gets a callback handler which is =
called for any attribute with iD=3Dtrue in order to compute a new value =
for this attribute. Moreover, such a callback handler could be used also =
for other things during the copy. It is like an application include, =
like those for the JET templates, for example. Another possibility would =
be to have an additional reflevtive method which is called in order to =
handle copies of ID-like attributes.
Currently, one typically overrides the copy method, calls super in it =
and then loops over every copied attribute, looks whether it should be =
changed in the copy and changes it, which is also not very performant.
In any case it is the application that is responsible for the =
computation of the copied attribute value. Only that in the case where a =
build-in possibility is provided, this solution would be more performant =
and nobody needs to have an own subclass copier which has to be used by =
other dependent applications.
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:grfocm$eul$1@build.eclipse.org...
Michael,
What you say is true, but ultimately it comes down to "what's the one =
right way to do it" because as soon as there is more than one way, how =
to choose which one is right? I.e., what algorithm can be used to =
ensure that the IDs are unique? And in what context do they have to be =
unique? For example, suppose I want to make three copies of some object =
and add each three times to the same resource. I'd still have a =
problem if I didn't take context into account. Also, if I =
systematically use some algorithm to transform the IDs, the odds will =
increase that an object will already exist with that ID. It just =
strikes me as one of those problems for which there isn't a perfect =
solution...
Michael M=FChlberg wrote:=20
Hello Ed,
yes, you are completely right.
I meant an OPTIONAL possibility to change an iD-tagged attribute, =
the default case should be like today. I only felt that the attribute-iD =
concept could also be used by the Ecore copier, only an idea, nothing =
else...
The thing with the override functionality gets problematic where =
metamodel federation is in the game. Imagine that someone creates a =
basic metamodel that gets used by other higher level metamodels, and you =
even don't know who is using your basic metamodel. But your basic =
metamodel has an ID in it that can only be copied by your adapted =
copier. Then every higher metamodel developer is forced to use only your =
adapted copier, he or she can not use the EcoreUtil one. And even worse, =
it can be that this problem is not covered during the development =
process, but later at the customer side.
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:grd5hd$dp4$1@build.eclipse.org...
Michael,
Comments below.
Michael M=FChlberg wrote:=20
I also have that problem with unique identifiers and the fact that the =
Ecore=20
copy function is not aware of them.
It's making a copy and that will include copying every feature, =
whether or not its an ID. After all, you might want to create a copy =
you can put into a different resource and would like the IDs to be the =
same as before.
Wouldn't it be a good idea for the Ecore copy function to provide an=20
(optional) call back mechanism for all attributes with iD=3Dtrue into =
the=20
caller of the copy function so that the ID can be changed for the copy? =
You can specialize the Copier itself, i.e., copyAttribute.
I=20
mean, an ID is an ID, and it should identify one single object uniquely, =
shouldn't it?
It's not a UUID. It's not required to be universally unique, only =
unique within a resource and who's to say what you're going to do with =
your copy and who's to say how best to create a new ID that will be =
unique in whatever context you plan to use the copy...
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message=20
news:grco27$uhb$1@build.eclipse.org...
Stephen,
You might well create copies but then not actually end up using them, as =
you've found out. Perhaps the override should be in the add/set =
command=20
that actually attaches the object to a container that's part of the=20
resource, though I suppose that gets tricky as you start to copy deeper=20
tree structures. Managing ID uniqueness is a tricky problem in general. =
After all, are you checking that nothing has already used the =
incremented=20
ID? Perhaps rather than a counter you should scan the resource to use =
the=20
next available unique ID.
Stephen Egan wrote:
Hi,
I need to override the default functionality of the =
InitializeCopyCommand=20
so as to increment objects' unique ID attribute. I have overriden the=20
doExecute() method to perform this action. All works well if I copy and =
paste within my editor (TreeViewer) using the menu or keyboard =
shortcuts.=20
However, if I try to copy using Drag and Drop while holding down the =
CTRL=20
key, the doExecute() method gets called repeatedly until I release the=20
mouse button - incrementing my ID counter each time.
Presumably I'm incrementing my ID in the wrong place, but am having=20
difficulty finding out where to do this so that it is only called when=20
the copy of the object is actually added to the model while using Drag=20
and Drop. Any help would be greatly appreciated.
//Stephen Egan
=20
------=_NextPart_000_0019_01C9B82A.7ABBB930
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META content=3Dtext/html;charset=3DISO-8859-1 =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702"></HEAD>
<BODY dir=3Dltr bgColor=3D#ffffff text=3D#000000>
<DIV><FONT size=3D2 face=3DArial>Hello Ed,</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>in my opinion implementing the =
"<STRONG>one=20
</STRONG>right way" is not necessary, just "<STRONG>two </STRONG>right =
ways" are=20
going to be implemented :)</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>In this special case it would be =
sufficient to=20
provide an <STRONG>additional </STRONG>second copy method in =
EcoreUtil,=20
that gets a callback handler which is called for any attribute with =
iD=3Dtrue in=20
order to compute a new value for this attribute. Moreover, such a =
callback=20
handler could be used also for other things during the copy. It is like =
an=20
application include, like those for the JET templates, for example. =
Another=20
possibility would be to have an additional reflevtive method which is =
called in=20
order to handle copies of ID-like attributes.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV><FONT size=3D2 =
face=3DArial>
<DIV><FONT size=3D2 face=3DArial>Currently, one typically overrides the =
copy method,=20
calls super in it and then loops over every copied attribute, looks =
whether it=20
should be changed in the copy and changes it, which is also not very=20
performant.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV>In any case it is the application that is responsible for the =
computation=20
of the copied attribute value. Only that in the case where a build-in=20
possibility is provided, this solution would be more performant and =
nobody needs=20
to have an own subclass copier which has to be used by other dependent=20
applications.</DIV>
<DIV> </DIV>
<DIV>Ciao, Michael</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:grfocm$eul$1@build.eclipse.org">news:grfocm$eul$1@build.ecli=
pse.org</A>...</DIV>Michael,<BR><BR>What=20
you say is true, but ultimately it comes down to "what's the one right =
way to=20
do it" because as soon as there is more than one way, how to choose =
which one=20
is right? I.e., what algorithm can be used to ensure that =
the IDs=20
are unique? And in what context do they have to be unique? For =
example,=20
suppose I want to make three copies of some object and add each =
three=20
times to the same resource. I'd still have a problem if I didn't =
take=20
context into account. Also, if I systematically use some =
algorithm to=20
transform the IDs, the odds will increase that an object will already =
exist=20
with that ID. It just strikes me as one of those problems for =
which=20
there isn't a perfect solution...<BR><BR><BR>Michael M=FChlberg wrote: =
<BLOCKQUOTE cite=3Dmid:grfnd4$9vp$1@build.eclipse.org type=3D"cite">
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<STYLE></STYLE>
<DIV><FONT size=3D2 face=3DArial>Hello Ed,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>yes, you are completely =
right.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>I meant an OPTIONAL possibility to =
change an=20
iD-tagged attribute, the default case should be like today. I only =
felt that=20
the attribute-iD concept could also be used by the Ecore copier, =
only an=20
idea, nothing else...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>The thing with the override =
functionality gets=20
problematic where metamodel federation is in the game. Imagine that =
someone=20
creates a basic metamodel that gets used by other higher level =
metamodels,=20
and you even don't know who is using your basic metamodel. But your =
basic=20
metamodel has an ID in it that can only be copied by your adapted =
copier.=20
Then every higher metamodel developer is forced to use only your =
adapted=20
copier, he or she can not use the EcoreUtil one. And even worse, it =
can be=20
that this problem is not covered during the development process, but =
later=20
at the customer side.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>Ciao, Michael</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: rgb(0,0,0) 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" <<A href=3D"mailto:Ed.Merks@gmail.com"=20
moz-do-not-send=3D"true">Ed.Merks@gmail.com</A>> wrote in =
message <A=20
href=3D"news:grd5hd$dp4$1@build.eclipse.org"=20
=
moz-do-not-send=3D"true">news:grd5hd$dp4$1@build.eclipse.org</A>...</DIV>=
Michael,<BR><BR>Comments=20
below.<BR><BR>Michael M=FChlberg wrote:=20
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">I also have that problem with unique =
identifiers and the fact that the Ecore=20
copy function is not aware of them.
</PRE></BLOCKQUOTE>It's making a copy and that will include copying=20
every feature, whether or not its an ID. After all, you =
might want=20
to create a copy you can put into a different resource and would =
like the=20
IDs to be the same as before.<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Wouldn't it be a good idea for the Ecore =
copy function to provide an=20
(optional) call back mechanism for all attributes with iD=3Dtrue into =
the=20
caller of the copy function so that the ID can be changed for the copy? =
</PRE></BLOCKQUOTE>You=20
can specialize the Copier itself, i.e., copyAttribute.<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">I=20
mean, an ID is an ID, and it should identify one single object uniquely, =
shouldn't it?
</PRE></BLOCKQUOTE>It's not a UUID. It's not required to be=20
universally unique, only unique within a resource and who's to say =
what=20
you're going to do with your copy and who's to say how best to =
create a=20
new ID that will be unique in whatever context you plan to use the =
copy...<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Ciao, Michael
"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:Ed.Merks@gmail.com" =
moz-do-not-send=3D"true"><Ed.Merks@gmail.com></A> wrote in message =
<A class=3Dmoz-txt-link-freetext =
href=3D"news:grco27$uhb$1@build.eclipse.org" =
moz-do-not-send=3D"true">news:grco27$uhb$1@build.eclipse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Stephen,
You might well create copies but then not actually end up using them, as =
you've found out. Perhaps the override should be in the add/set =
command=20
that actually attaches the object to a container that's part of the=20
resource, though I suppose that gets tricky as you start to copy deeper=20
tree structures. Managing ID uniqueness is a tricky problem in general. =
After all, are you checking that nothing has already used the =
incremented=20
ID? Perhaps rather than a counter you should scan the resource to use =
the=20
next available unique ID.
Stephen Egan wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi,
I need to override the default functionality of the =
InitializeCopyCommand=20
so as to increment objects' unique ID attribute. I have overriden the=20
doExecute() method to perform this action. All works well if I copy and =
paste within my editor (TreeViewer) using the menu or keyboard =
shortcuts.=20
However, if I try to copy using Drag and Drop while holding down the =
CTRL=20
key, the doExecute() method gets called repeatedly until I release the=20
mouse button - incrementing my ID counter each time.
Presumably I'm incrementing my ID in the wrong place, but am having=20
difficulty finding out where to do this so that it is only called when=20
the copy of the object is actually added to the model while using Drag=20
and Drop. Any help would be greatly appreciated.
//Stephen Egan
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->
=
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE ></BODY></HTML>
------=_NextPart_000_0019_01C9B82A.7ABBB930--
|
|
|
| Re: Overriding InitializeCopyCommand to increment ID [message #429096 is a reply to message #429095] |
Wed, 08 April 2009 10:03 |
Ed Merks
Messages: 33218
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030102030401090803070203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Michael,
I'm not sure how a callback is different or less performant than a
derived copier with an override of copyAttribute, which involves dealing
with just that one attribute, so no looping, and for this ID case, one
would not call super because it's being handled in a specialized way In
both cases you need a derived something that you'd need to get other
people to use if they wanted the specialized behavior you've defined.
Also, by the time all the different things you allude to are handled, I
imagine the callback API would end up looking much like methods in the
copier itself currently, making the solutions appear effectively
identical in how they are designed and used. Note for example that it's
typically important to have access to the map that the copier is
building, so likely the callback would need to be passed the copier. In
other words, the callback API methods would involve more arguments than
the current traversal methods. Not only that, the calls between the
copier and the handler would perform less well (calling a method on a
interface is significantly more expensive than calling a method on a
class) than simple method invocations within the one copier instance
now, i.e., a handler will be less performant than the alternative of
deriving from the copier. Of course it could be really early and my
imagination and coffee haven't properly kicked in yet.
Michael M
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Overriding InitializeCopyCommand to increment ID [message #429124 is a reply to message #429096] |
Thu, 09 April 2009 09:11 |
Michael Mühlberg
Messages: 33
Registered: July 2009 |
Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0027_01C9B903.F45E9710
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Ed,
as you mentioned, overriding copyAttribute is ok. I didn't see that.
My main point is the problem that using metamodels can not use the Ecore =
copy function in the case where the used metamodel requires a special =
one. The using application has to use a special copy function. I also =
see now that having a second copy method, with a call back handler in =
it, also wouldn't solve that problem beause in this case too, the =
application would have to know that call back handler and even worse, =
what is when the using application uses more that one metamodel that =
would require different call back handlers!
So, the only solution would be that the basic metamodel would be able to =
define how its attribute should behave during a copy directly in the =
metamodel. This could perhaps be made via an additional switch in the =
genmodel (generateCopyHandler =3D true/false) which then generates an =
additional method in the hosting class interface and impl (which would =
have to be implemented manually) or via an additional setting in the =
genmodel where one can define a class that handles the attribute copy or =
something similar.
The necessary infrastructure for this would probably make the copy a bit =
more inperformant, ok.
To sum up, we have to balance between the following 2 facts: performance =
and consumability for using metamodels. My opinion goes clearly into the =
direction of consumability because this is an essential part of thinking =
during my work experience :)
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:grhspg$ia0$1@build.eclipse.org...
Michael,
I'm not sure how a callback is different or less performant than a =
derived copier with an override of copyAttribute, which involves dealing =
with just that one attribute, so no looping, and for this ID case, one =
would not call super because it's being handled in a specialized way In =
both cases you need a derived something that you'd need to get other =
people to use if they wanted the specialized behavior you've defined. =
Also, by the time all the different things you allude to are handled, I =
imagine the callback API would end up looking much like methods in the =
copier itself currently, making the solutions appear effectively =
identical in how they are designed and used. Note for example that it's =
typically important to have access to the map that the copier is =
building, so likely the callback would need to be passed the copier. In =
other words, the callback API methods would involve more arguments than =
the current traversal methods. Not only that, the calls between the =
copier and the handler would perform less well (calling a method on a =
interface is significantly more expensive than calling a method on a =
class) than simple method invocations within the one copier instance =
now, i.e., a handler will be less performant than the alternative of =
deriving from the copier. Of course it could be really early and my =
imagination and coffee haven't properly kicked in yet.
Michael M=FChlberg wrote:=20
Hello Ed,
in my opinion implementing the "one right way" is not necessary, =
just "two right ways" are going to be implemented :)
In this special case it would be sufficient to provide an additional =
second copy method in EcoreUtil, that gets a callback handler which is =
called for any attribute with iD=3Dtrue in order to compute a new value =
for this attribute. Moreover, such a callback handler could be used also =
for other things during the copy. It is like an application include, =
like those for the JET templates, for example. Another possibility would =
be to have an additional reflevtive method which is called in order to =
handle copies of ID-like attributes.
Currently, one typically overrides the copy method, calls super in =
it and then loops over every copied attribute, looks whether it should =
be changed in the copy and changes it, which is also not very =
performant.
In any case it is the application that is responsible for the =
computation of the copied attribute value. Only that in the case where a =
build-in possibility is provided, this solution would be more performant =
and nobody needs to have an own subclass copier which has to be used by =
other dependent applications.
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:grfocm$eul$1@build.eclipse.org...
Michael,
What you say is true, but ultimately it comes down to "what's the =
one right way to do it" because as soon as there is more than one way, =
how to choose which one is right? I.e., what algorithm can be used to =
ensure that the IDs are unique? And in what context do they have to be =
unique? For example, suppose I want to make three copies of some object =
and add each three times to the same resource. I'd still have a =
problem if I didn't take context into account. Also, if I =
systematically use some algorithm to transform the IDs, the odds will =
increase that an object will already exist with that ID. It just =
strikes me as one of those problems for which there isn't a perfect =
solution...
Michael M=FChlberg wrote:=20
Hello Ed,
yes, you are completely right.
I meant an OPTIONAL possibility to change an iD-tagged =
attribute, the default case should be like today. I only felt that the =
attribute-iD concept could also be used by the Ecore copier, only an =
idea, nothing else...
The thing with the override functionality gets problematic where =
metamodel federation is in the game. Imagine that someone creates a =
basic metamodel that gets used by other higher level metamodels, and you =
even don't know who is using your basic metamodel. But your basic =
metamodel has an ID in it that can only be copied by your adapted =
copier. Then every higher metamodel developer is forced to use only your =
adapted copier, he or she can not use the EcoreUtil one. And even worse, =
it can be that this problem is not covered during the development =
process, but later at the customer side.
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message =
news:grd5hd$dp4$1@build.eclipse.org...
Michael,
Comments below.
Michael M=FChlberg wrote:=20
I also have that problem with unique identifiers and the fact that the =
Ecore=20
copy function is not aware of them.
It's making a copy and that will include copying every feature, =
whether or not its an ID. After all, you might want to create a copy =
you can put into a different resource and would like the IDs to be the =
same as before.
Wouldn't it be a good idea for the Ecore copy function to provide an=20
(optional) call back mechanism for all attributes with iD=3Dtrue into =
the=20
caller of the copy function so that the ID can be changed for the copy? =
You can specialize the Copier itself, i.e., copyAttribute.
I=20
mean, an ID is an ID, and it should identify one single object uniquely, =
shouldn't it?
It's not a UUID. It's not required to be universally unique, only =
unique within a resource and who's to say what you're going to do with =
your copy and who's to say how best to create a new ID that will be =
unique in whatever context you plan to use the copy...
Ciao, Michael
"Ed Merks" <Ed.Merks@gmail.com> wrote in message=20
news:grco27$uhb$1@build.eclipse.org...
Stephen,
You might well create copies but then not actually end up using them, as =
you've found out. Perhaps the override should be in the add/set =
command=20
that actually attaches the object to a container that's part of the=20
resource, though I suppose that gets tricky as you start to copy deeper=20
tree structures. Managing ID uniqueness is a tricky problem in general. =
After all, are you checking that nothing has already used the =
incremented=20
ID? Perhaps rather than a counter you should scan the resource to use =
the=20
next available unique ID.
Stephen Egan wrote:
Hi,
I need to override the default functionality of the =
InitializeCopyCommand=20
so as to increment objects' unique ID attribute. I have overriden the=20
doExecute() method to perform this action. All works well if I copy and =
paste within my editor (TreeViewer) using the menu or keyboard =
shortcuts.=20
However, if I try to copy using Drag and Drop while holding down the =
CTRL=20
key, the doExecute() method gets called repeatedly until I release the=20
mouse button - incrementing my ID counter each time.
Presumably I'm incrementing my ID in the wrong place, but am having=20
difficulty finding out where to do this so that it is only called when=20
the copy of the object is actually added to the model while using Drag=20
and Drop. Any help would be greatly appreciated.
//Stephen Egan
=20
------=_NextPart_000_0027_01C9B903.F45E9710
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META content=3Dtext/html;charset=3DISO-8859-1 =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702"></HEAD>
<BODY bgColor=3D#ffffff text=3D#000000>
<DIV><FONT size=3D2 face=3DArial>Hello Ed,</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>as you mentioned, overriding =
copyAttribute is ok. I=20
didn't see that.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>My main point is the problem that using =
metamodels=20
can not use the Ecore copy function in the case where the used metamodel =
requires a special one. The using application has to use a special copy=20
function. I also see now that having a second copy method, with a call =
back=20
handler in it, also wouldn't solve that problem beause in this case too, =
the=20
application would have to know that call back handler and even worse, =
what is=20
when the using application uses more that one metamodel that would =
require=20
different call back handlers!</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>So, the only solution would be that the =
basic=20
metamodel would be able to define how its attribute should behave during =
a copy=20
<STRONG>directly in the metamodel</STRONG>. This could perhaps be made =
via an=20
additional switch in the genmodel (generateCopyHandler =3D true/false) =
which then=20
generates an additional method in the hosting class interface and impl =
(which=20
would have to be implemented manually) or via an additional setting in =
the=20
genmodel where one can define a class that handles the attribute copy or =
something similar.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV>
<DIV><FONT size=3D2 face=3DArial>The necessary infrastructure for this =
would=20
probably make the copy a bit more inperformant, ok.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV></DIV>
<DIV><FONT size=3D2 face=3DArial>To sum up, we have to balance between =
the following=20
2 facts: performance and consumability for using metamodels. My opinion =
goes=20
clearly into the direction of consumability because this is an essential =
part of=20
thinking during my work experience :)</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>Ciao, Michael</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" <<A=20
href=3D"mailto:Ed.Merks@gmail.com">Ed.Merks@gmail.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:grhspg$ia0$1@build.eclipse.org">news:grhspg$ia0$1@build.ecli=
pse.org</A>...</DIV>Michael,<BR><BR>I'm=20
not sure how a callback is different or less performant than a derived =
copier=20
with an override of copyAttribute, which involves dealing with just =
that one=20
attribute, so no looping, and for this ID case, one would not call =
super=20
because it's being handled in a specialized way In both cases =
you need a=20
derived something that you'd need to get other people to use if they =
wanted=20
the specialized behavior you've defined. Also, by the time =
all the=20
different things you allude to are handled, I imagine the callback API =
would=20
end up looking much like methods in the copier itself currently, =
making the=20
solutions appear effectively identical in how they are designed and=20
used. Note for example that it's typically important to have =
access to=20
the map that the copier is building, so likely the callback would need =
to be=20
passed the copier. In other words, the callback API methods =
would=20
involve more arguments than the current traversal methods. Not =
only=20
that, the calls between the copier and the handler would perform less =
well=20
(calling a method on a interface is significantly more expensive than =
calling=20
a method on a class) than simple method invocations within the one =
copier=20
instance now, i.e., a handler will be less performant than the =
alternative of=20
deriving from the copier. Of course it could be really early and =
my=20
imagination and coffee haven't properly kicked in =
yet.<BR><BR><BR>Michael=20
M=FChlberg wrote:=20
<BLOCKQUOTE cite=3Dmid:grhiti$802$1@build.eclipse.org type=3D"cite">
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<DIV><FONT size=3D2 face=3DArial>Hello Ed,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>in my opinion implementing the =
"<STRONG>one=20
</STRONG>right way" is not necessary, just "<STRONG>two =
</STRONG>right ways"=20
are going to be implemented :)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>In this special case it would be =
sufficient to=20
provide an <STRONG>additional </STRONG>second copy method in =
EcoreUtil,=20
that gets a callback handler which is called for any attribute with =
iD=3Dtrue=20
in order to compute a new value for this attribute. Moreover, such a =
callback handler could be used also for other things during the =
copy. It is=20
like an application include, like those for the JET templates, for =
example.=20
Another possibility would be to have an additional reflevtive method =
which=20
is called in order to handle copies of ID-like =
attributes.</FONT></DIV>
<DIV> </DIV><FONT size=3D2 face=3DArial></FONT>
<DIV><FONT size=3D2 face=3DArial><FONT size=3D2 =
face=3DArial>Currently, one=20
typically overrides the copy method, calls super in it and then =
loops over=20
every copied attribute, looks whether it should be changed in the =
copy and=20
changes it, which is also not very performant.</FONT></FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>In any case it is the application =
that is=20
responsible for the computation of the copied attribute value. Only =
that in=20
the case where a build-in possibility is provided, this solution =
would be=20
more performant and nobody needs to have an own subclass copier =
which has to=20
be used by other dependent applications.</FONT></DIV>
<DIV><FONT size=3D2 face=3DArial></FONT> </DIV>
<DIV><FONT size=3D2 face=3DArial>Ciao, Michael</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: rgb(0,0,0) 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" <<A href=3D"mailto:Ed.Merks@gmail.com"=20
moz-do-not-send=3D"true">Ed.Merks@gmail.com</A>> wrote in =
message <A=20
href=3D"news:grfocm$eul$1@build.eclipse.org"=20
=
moz-do-not-send=3D"true">news:grfocm$eul$1@build.eclipse.org</A>...</DIV>=
Michael,<BR><BR>What=20
you say is true, but ultimately it comes down to "what's the one =
right way=20
to do it" because as soon as there is more than one way, how to =
choose=20
which one is right? I.e., what algorithm can be used =
to ensure=20
that the IDs are unique? And in what context do they have to =
be=20
unique? For example, suppose I want to make three copies of some =
object=20
and add each three times to the same resource. I'd =
still have=20
a problem if I didn't take context into account. Also, if I=20
systematically use some algorithm to transform the IDs, the odds =
will=20
increase that an object will already exist with that ID. It =
just=20
strikes me as one of those problems for which there isn't a =
perfect=20
solution...<BR><BR><BR>Michael M=FChlberg wrote:=20
<BLOCKQUOTE cite=3Dmid:grfnd4$9vp$1@build.eclipse.org =
type=3D"cite">
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<STYLE></STYLE>
<DIV><FONT size=3D2 face=3DArial>Hello Ed,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>yes, you are completely =
right.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>I meant an OPTIONAL possibility =
to change=20
an iD-tagged attribute, the default case should be like today. I =
only=20
felt that the attribute-iD concept could also be used by the =
Ecore=20
copier, only an idea, nothing else...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>The thing with the override =
functionality=20
gets problematic where metamodel federation is in the game. =
Imagine that=20
someone creates a basic metamodel that gets used by other higher =
level=20
metamodels, and you even don't know who is using your basic =
metamodel.=20
But your basic metamodel has an ID in it that can only be copied =
by your=20
adapted copier. Then every higher metamodel developer is forced =
to use=20
only your adapted copier, he or she can not use the EcoreUtil =
one. And=20
even worse, it can be that this problem is not covered during =
the=20
development process, but later at the customer =
side.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2 face=3DArial>Ciao, Michael</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: rgb(0,0,0) 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"=20
dir=3Dltr>
<DIV>"Ed Merks" <<A href=3D"mailto:Ed.Merks@gmail.com"=20
moz-do-not-send=3D"true">Ed.Merks@gmail.com</A>> wrote in =
message <A=20
href=3D"news:grd5hd$dp4$1@build.eclipse.org"=20
=
moz-do-not-send=3D"true">news:grd5hd$dp4$1@build.eclipse.org</A>...</DIV>=
Michael,<BR><BR>Comments=20
below.<BR><BR>Michael M=FChlberg wrote:=20
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">I also have that problem with unique =
identifiers and the fact that the Ecore=20
copy function is not aware of them.
</PRE></BLOCKQUOTE>It's making a copy and that will include copying=20
every feature, whether or not its an ID. After all, you =
might=20
want to create a copy you can put into a different resource =
and would=20
like the IDs to be the same as before.<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Wouldn't it be a good idea for the Ecore =
copy function to provide an=20
(optional) call back mechanism for all attributes with iD=3Dtrue into =
the=20
caller of the copy function so that the ID can be changed for the copy? =
</PRE></BLOCKQUOTE>You=20
can specialize the Copier itself, i.e., copyAttribute.<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">I=20
mean, an ID is an ID, and it should identify one single object uniquely, =
shouldn't it?
</PRE></BLOCKQUOTE>It's not a UUID. It's not required to be=20
universally unique, only unique within a resource and who's to =
say=20
what you're going to do with your copy and who's to say how =
best to=20
create a new ID that will be unique in whatever context you =
plan to=20
use the copy...<BR>
<BLOCKQUOTE cite=3Dmid:grd4ep$7bu$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">Ciao, Michael
"Ed Merks" <A class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:Ed.Merks@gmail.com" =
moz-do-not-send=3D"true"><Ed.Merks@gmail.com></A> wrote in message =
<A class=3Dmoz-txt-link-freetext =
href=3D"news:grco27$uhb$1@build.eclipse.org" =
moz-do-not-send=3D"true">news:grco27$uhb$1@build.eclipse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Stephen,
You might well create copies but then not actually end up using them, as =
you've found out. Perhaps the override should be in the add/set =
command=20
that actually attaches the object to a container that's part of the=20
resource, though I suppose that gets tricky as you start to copy deeper=20
tree structures. Managing ID uniqueness is a tricky problem in general. =
After all, are you checking that nothing has already used the =
incremented=20
ID? Perhaps rather than a counter you should scan the resource to use =
the=20
next available unique ID.
Stephen Egan wrote:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Hi,
I need to override the default functionality of the =
InitializeCopyCommand=20
so as to increment objects' unique ID attribute. I have overriden the=20
doExecute() method to perform this action. All works well if I copy and =
paste within my editor (TreeViewer) using the menu or keyboard =
shortcuts.=20
However, if I try to copy using Drag and Drop while holding down the =
CTRL=20
key, the doExecute() method gets called repeatedly until I release the=20
mouse button - incrementing my ID counter each time.
Presumably I'm incrementing my ID in the wrong place, but am having=20
difficulty finding out where to do this so that it is only called when=20
the copy of the object is actually added to the model while using Drag=20
and Drop. Any help would be greatly appreciated.
//Stephen Egan
</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->
=
</PRE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE ></BLOCKQUOTE></=
BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0027_01C9B903.F45E9710--
|
|
| |
Goto Forum:
Current Time: Wed Sep 25 22:51:04 GMT 2024
Powered by FUDForum. Page generated in 0.05064 seconds |
] 
Search
Help
Register
Login
Home
