Home » Modeling » EMF » Distinguish 'Remove from Containment' from 'Set new Container' in an Adapter
| Distinguish 'Remove from Containment' from 'Set new Container' in an Adapter [message #426912] |
Sun, 25 January 2009 11:13  |
 Felix Dorner
Messages: 676
Registered: July 2009 |
Senior Member |
|
|
Hey,
I execute a set command, to move an EObject o within the containment
hierarchy. The command is created as follows:
SetCommand.create(domain, o, MyPackage.Literals.A_REFERENCE, newOwner);
where A_REFERENCE is the opposite of the containment reference, and
newOwner the new container.
Observing the command execution with an Adapter, the first received
notification is received from o and is of type 'SET',
feature:A_REFERENCE, with newValue = null.
This looks like o was removed from the containment hierarchy. Now it
seems hard to distinguish between the two cases 'o moved' and 'o removed'.
And when I finally receive the 'SET, A_REFERENCE, newValue: newOwner
it seems hard to distinguish between 'o was moved', or 'o is a new
object in the hierarchy'.
The only way that comes to mind is to maintain an internal cache of
those notifications inside my adapter. When a new notification arrives,
look at the cache to come to the right conclusion. Am I missing
something here?
Thanks for comments,
Felix
|
|
| |
| Re: Distinguish 'Remove from Containment' from 'Set new Container' in an Adapter [message #426914 is a reply to message #426912] |
Sun, 25 January 2009 12:14  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080603050402030908000208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Felix,
Comments below.
Felix Dorner wrote:
> Hey,
>
> I execute a set command, to move an EObject o within the containment
> hierarchy.
You shouldn't do that generally. Commands like Set and Add will *not
*invoke commands to do inverse updating and while the model will do that
anyway, those actions are not recorded as commands and aren't undone.
> The command is created as follows:
>
> SetCommand.create(domain, o, MyPackage.Literals.A_REFERENCE, newOwner);
>
> where A_REFERENCE is the opposite of the containment reference, and
> newOwner the new container.
>
> Observing the command execution with an Adapter, the first received
> notification is received from o and is of type 'SET',
> feature:A_REFERENCE, with newValue = null.
>
> This looks like o was removed from the containment hierarchy. Now it
> seems hard to distinguish between the two cases 'o moved' and 'o
> removed'.
When doing these things at the model level, you get the notification
*after *all the ends are updated, so you could check the current state.
But as commands, moving really is remove/unset followed by add/set.
Something like cut followed 5 minutes later by a paste will look the same.
>
> And when I finally receive the 'SET, A_REFERENCE, newValue: newOwner
> it seems hard to distinguish between 'o was moved', or 'o is a new
> object in the hierarchy'.
It does, but with cut and paste, there's the same problem though with a
very long, potentially indefinite, interval in between. How would you
handle that?
>
> The only way that comes to mind is to maintain an internal cache of
> those notifications inside my adapter. When a new notification
> arrives, look at the cache to come to the right conclusion. Am I
> missing something here?
Probably the problem is worse than you've considered. I'm not sure what
goal you're trying to accomplish...
>
> Thanks for comments,
> Felix
>
>
>
>
>
>
>
>
--------------080603050402030908000208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Felix,<br>
<br>
Comments below.<br>
<br>
Felix Dorner wrote:
<blockquote cite="mid:glhhgi$m02$1@build.eclipse.org" type="cite">Hey,
<br>
<br>
I execute a set command, to move an EObject o within the containment
hierarchy. </blockquote>
You shouldn't do that generally. Commands like Set and Add will <b>not
</b>invoke commands to do inverse updating and while the model will do
that anyway, those actions are not recorded as commands and aren't
undone.<br>
<blockquote cite="mid:glhhgi$m02$1@build.eclipse.org" type="cite">The
command is created as follows:
<br>
<br>
SetCommand.create(domain, o, MyPackage.Literals.A_REFERENCE, newOwner);
<br>
<br>
where A_REFERENCE is the opposite of the containment reference, and
newOwner the new container.
<br>
<br>
Observing the command execution with an Adapter, the first received
notification is received from o and is of type 'SET',
feature:A_REFERENCE, with newValue = null.
<br>
<br>
This looks like o was removed from the containment hierarchy. Now it
seems hard to distinguish between the two cases 'o moved' and 'o
removed'.
<br>
</blockquote>
When doing these things at the model level, you get the notification <b>after
</b>all the ends are updated, so you could check the current state.
But as commands, moving really is remove/unset followed by add/set.
Something like cut followed 5 minutes later by a paste will look the
same.<br>
<blockquote cite="mid:glhhgi$m02$1@build.eclipse.org" type="cite"><br>
And when I finally receive the 'SET, A_REFERENCE, newValue: newOwner
<br>
it seems hard to distinguish between 'o was moved', or 'o is a new
object in the hierarchy'.
<br>
</blockquote>
It does, but with cut and paste, there's the same problem though with a
very long, potentially indefinite, interval in between. How would you
handle that?<br>
<blockquote cite="mid:glhhgi$m02$1@build.eclipse.org" type="cite"><br>
The only way that comes to mind is to maintain an internal cache of
those notifications inside my adapter. When a new notification arrives,
look at the cache to come to the right conclusion. Am I missing
something here?
<br>
</blockquote>
Probably the problem is worse than you've considered. I'm not sure
what goal you're trying to accomplish...<br>
<blockquote cite="mid:glhhgi$m02$1@build.eclipse.org" type="cite"><br>
Thanks for comments,
<br>
Felix
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
</body>
</html>
--------------080603050402030908000208--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Distinguish 'Remove from Containment' from 'Set new Container' in an Adapter [message #426915 is a reply to message #426914] |
Sun, 25 January 2009 12:52 |
Felix Dorner
Messages: 676
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
>> I execute a set command, to move an EObject o within the containment
>> hierarchy.
> You shouldn't do that generally. Commands like Set and Add will *not
> *invoke commands to do inverse updating and while the model will do that
> anyway, those actions are not recorded as commands and aren't undone.
Okay.
>> And when I finally receive the 'SET, A_REFERENCE, newValue: newOwner
>> it seems hard to distinguish between 'o was moved', or 'o is a new
>> object in the hierarchy'.
> It does, but with cut and paste, there's the same problem though with a
> very long, potentially indefinite, interval in between. How would you
> handle that?
Uh, oh... :-|
> I'm not sure what goal you're trying to accomplish...
The model elements that I like to move around are something very similar
to eclipse's IResources, i.e. stuff that's associated with arbitrary
data on disk. So far, I handle 'moving' by a special composite command
that basically executes the set command mentioned above, plus moving the
associated data. I probably make the first mistake already here, as I
should move the data-copying behavior into the model objects, or install
some kind of adapter that performs the copying/moving...
Now, I want to allow arbitrary postprocessing of that data after a move,
imagine something like issuing a retroactive svn move command.
I guess I'm pretty stuck at this point and will have to rethink my
design :-/ I guess that just happens..
Thanks again for your always valuable advice,
Felix
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:35:42 GMT 2024
Powered by FUDForum. Page generated in 0.03776 seconds |
] 
Search
Help
Register
Login
Home
