Home » Modeling » EMF » CompoundCommand containing multiple RecordingCommands does not undo correctly
|
| Re: CompoundCommand containing multiple RecordingCommands does not undo correctly [message #416595 is a reply to message #416594] |
Thu, 07 February 2008 10:57   |
 PÃ¥l Stenslet
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
I have looked more into this, and the situation is slighlty different than
described in th eprevious message. There is no sharing of
CompositeChangeDescription going on, after all. There are two, nested
transactions involved:
(1) The GUI issues a CompoundCommand containing a single RecordingCommand.
(2) On preCommit, A ResourceSetListener issues a trigger command (also a
CompoundCommand containing a RecordingCommand). This is executed in a nested
transaction.
(3) On undo, the trigger command is undone first, with a
CompositeChangeDescription containing a single ChangeDescriptionImpl
(listing only the objects directly changed by the trigger command).
(4) Continuing with the undo, the GUI command is undone, with a
CompositeChangeDescription containing both a ChangeDescriptionImpl (listing
only the objects directly changed by the GUI command), and a
CommandChangeDescription listing the trigger command. Hence, the trigger
command is undone twice (effectively redoing it).
Upon undo, the trigger command is found in two places:
- As part of the ConditionalRedoCommand.Compound at the top of the command
stack
- As part of the CompositeChangeDescription for the GUI command transaction.
This does not seem right to me. I doubt this is a bug, but I can't figure
out where I'm going wrong.
I will be most thankful for any suggestions.
"EMF" <paal.stenslet@exie.com> wrote in message
news:foegip$94j$1@build.eclipse.org...
> We have just started using EMF Transactions, mainly for the appearent
> simplicity of RecordingCommand, which releaves our programmers from the
> burden of looking up features and create compound commands. Instead they
> merely wrap the direct model manipulations in a RecordingCommand.
>
> As a result of this, we get into situations where we contruct
> CompondCommands containing more than one RecordingCommand (which seems
> perfectly reasonable to me). (Note: The RecordingCommands are not added by
> a ResourceSetListener.)
>
> These CompoundCommands execute fine, with the expected result. However,
> when undoing such a CompoundCommand, it appearantly attempts to undo the
> entire transaction (i.e. its CompositeChangeDescription) for each of the
> contained RecordingCommands. This yields unexpected results.
>
> I have looked for ways to override, but this behavior of the transaction
> handling classes appears to be either private or final.
>
> I get the feeling that it is something I have overlooked. Is it possible
> to include more than one RecordingCommand in an undoable CompoundCommand?
|
|
|
| Re: CompoundCommand containing multiple RecordingCommands does not undo correctly [message #416624 is a reply to message #416595] |
Fri, 08 February 2008 13:56 |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, EMF,
See some comments in-line, below.
HTH,
Christian
EMF wrote:
> I have looked more into this, and the situation is slighlty different than
> described in th eprevious message. There is no sharing of
> CompositeChangeDescription going on, after all. There are two, nested
> transactions involved:
>
> (1) The GUI issues a CompoundCommand containing a single RecordingCommand.
I'm not sure that RecordingCommands mix well with CompoundCommands. The
command-stack will create a transaction in which to run the compound, but
it's the compound that executes the RecordingCommands that it contains, and
it doesn't know how to create nested transactions for its children. If
there should be multiple such RecordingCommands, they will all think that
the single transaction created for the compound is their transaction. If
on undo, they all try to apply the change description, bad results will
ensue.
I need to look into this.
> (2) On preCommit, A ResourceSetListener issues a trigger command (also a
> CompoundCommand containing a RecordingCommand). This is executed in a
> nested transaction.
>
> (3) On undo, the trigger command is undone first, with a
> CompositeChangeDescription containing a single ChangeDescriptionImpl
> (listing only the objects directly changed by the trigger command).
>
> (4) Continuing with the undo, the GUI command is undone, with a
> CompositeChangeDescription containing both a ChangeDescriptionImpl
> (listing only the objects directly changed by the GUI command), and a
> CommandChangeDescription listing the trigger command. Hence, the trigger
> command is undone twice (effectively redoing it).
Yes. I'm not sure that RecordingCommands work well as triggers. I see that
you have already raised a bug with a reproducible test case. Thanks for
that! I shall look into it, forthwith.
> Upon undo, the trigger command is found in two places:
> - As part of the ConditionalRedoCommand.Compound at the top of the command
> stack
> - As part of the CompositeChangeDescription for the GUI command
> transaction.
>
> This does not seem right to me. I doubt this is a bug, but I can't figure
> out where I'm going wrong.
Yes, I'd say it is a bug, and you have already raised it. :-)
> I will be most thankful for any suggestions.
>
> "EMF" <paal.stenslet@exie.com> wrote in message
> news:foegip$94j$1@build.eclipse.org...
>> We have just started using EMF Transactions, mainly for the appearent
>> simplicity of RecordingCommand, which releaves our programmers from the
>> burden of looking up features and create compound commands. Instead they
>> merely wrap the direct model manipulations in a RecordingCommand.
>>
>> As a result of this, we get into situations where we contruct
>> CompondCommands containing more than one RecordingCommand (which seems
>> perfectly reasonable to me). (Note: The RecordingCommands are not added
>> by a ResourceSetListener.)
>>
>> These CompoundCommands execute fine, with the expected result. However,
>> when undoing such a CompoundCommand, it appearantly attempts to undo the
>> entire transaction (i.e. its CompositeChangeDescription) for each of the
>> contained RecordingCommands. This yields unexpected results.
>>
>> I have looked for ways to override, but this behavior of the transaction
>> handling classes appears to be either private or final.
>>
>> I get the feeling that it is something I have overlooked. Is it possible
>> to include more than one RecordingCommand in an undoable CompoundCommand?
|
|
|
| Re: CompoundCommand containing multiple RecordingCommands does not undo correctly [message #416637 is a reply to message #416624] |
Fri, 08 February 2008 17:06 |
PÃ¥l Stenslet
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi, Christian
Thanks for your comments.
With the workaround mentioned in my bug report, I find RecordingCommands
most useful. FYI RecordingCommands work well as triggers and they mix well
with
CompundCommands (and other Commands). We are using EMF in a non-eclipse
client. We started out without EMF transactions, but after migration to EMF
2.3 we were finally able to isolate the EMF transaction support for use
outside Eclipse. The other people working on the project are very happy with
the simplified programming model provided by RecordingCommand.
Regards,
Paul
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fohn1u$9nh$1@build.eclipse.org...
> Hi, EMF,
>
> See some comments in-line, below.
>
> HTH,
>
> Christian
>
>
> EMF wrote:
>
>> I have looked more into this, and the situation is slighlty different
>> than
>> described in th eprevious message. There is no sharing of
>> CompositeChangeDescription going on, after all. There are two, nested
>> transactions involved:
>>
>> (1) The GUI issues a CompoundCommand containing a single
>> RecordingCommand.
>
> I'm not sure that RecordingCommands mix well with CompoundCommands. The
> command-stack will create a transaction in which to run the compound, but
> it's the compound that executes the RecordingCommands that it contains,
> and
> it doesn't know how to create nested transactions for its children. If
> there should be multiple such RecordingCommands, they will all think that
> the single transaction created for the compound is their transaction. If
> on undo, they all try to apply the change description, bad results will
> ensue.
>
> I need to look into this.
>
>
>> (2) On preCommit, A ResourceSetListener issues a trigger command (also a
>> CompoundCommand containing a RecordingCommand). This is executed in a
>> nested transaction.
>>
>> (3) On undo, the trigger command is undone first, with a
>> CompositeChangeDescription containing a single ChangeDescriptionImpl
>> (listing only the objects directly changed by the trigger command).
>>
>> (4) Continuing with the undo, the GUI command is undone, with a
>> CompositeChangeDescription containing both a ChangeDescriptionImpl
>> (listing only the objects directly changed by the GUI command), and a
>> CommandChangeDescription listing the trigger command. Hence, the trigger
>> command is undone twice (effectively redoing it).
>
> Yes. I'm not sure that RecordingCommands work well as triggers. I see
> that
> you have already raised a bug with a reproducible test case. Thanks for
> that! I shall look into it, forthwith.
>
>
>> Upon undo, the trigger command is found in two places:
>> - As part of the ConditionalRedoCommand.Compound at the top of the
>> command
>> stack
>> - As part of the CompositeChangeDescription for the GUI command
>> transaction.
>>
>> This does not seem right to me. I doubt this is a bug, but I can't figure
>> out where I'm going wrong.
>
> Yes, I'd say it is a bug, and you have already raised it. :-)
>
>
>> I will be most thankful for any suggestions.
>>
>> "EMF" <paal.stenslet@exie.com> wrote in message
>> news:foegip$94j$1@build.eclipse.org...
>>> We have just started using EMF Transactions, mainly for the appearent
>>> simplicity of RecordingCommand, which releaves our programmers from the
>>> burden of looking up features and create compound commands. Instead they
>>> merely wrap the direct model manipulations in a RecordingCommand.
>>>
>>> As a result of this, we get into situations where we contruct
>>> CompondCommands containing more than one RecordingCommand (which seems
>>> perfectly reasonable to me). (Note: The RecordingCommands are not added
>>> by a ResourceSetListener.)
>>>
>>> These CompoundCommands execute fine, with the expected result. However,
>>> when undoing such a CompoundCommand, it appearantly attempts to undo the
>>> entire transaction (i.e. its CompositeChangeDescription) for each of the
>>> contained RecordingCommands. This yields unexpected results.
>>>
>>> I have looked for ways to override, but this behavior of the transaction
>>> handling classes appears to be either private or final.
>>>
>>> I get the feeling that it is something I have overlooked. Is it possible
>>> to include more than one RecordingCommand in an undoable
>>> CompoundCommand?
>
|
|
|
| Re: CompoundCommand containing multiple RecordingCommands does not undo correctly [message #416664 is a reply to message #416637] |
Mon, 11 February 2008 16:59 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Paul,
Yes, I thought we had done something to make RecordingCommands usable as
triggers. I guess it's just the aggregation in a CompoundCommand for
execution on the CommandStack that was overlooked and needs to be resolved
on your bug.
The programming model of the RecordingCommand is convenient, yes. That's
why we provided it in the first place :-)
BTW, did you know that the RecordingCommand seems to have inspired the core
EMF component to provide a similar facility? If you don't need the rest of
the transaction capability, have a look at the
org.eclipse.emf.edit.command.ChangeCommand.
cW
Pål Stenslet wrote:
> Hi, Christian
>
> Thanks for your comments.
>
> With the workaround mentioned in my bug report, I find RecordingCommands
> most useful. FYI RecordingCommands work well as triggers and they mix well
> with
> CompundCommands (and other Commands). We are using EMF in a non-eclipse
> client. We started out without EMF transactions, but after migration to
> EMF 2.3 we were finally able to isolate the EMF transaction support for
> use outside Eclipse. The other people working on the project are very
> happy with the simplified programming model provided by RecordingCommand.
>
> Regards,
> Paul
-----8<-----
|
|
|
| Re: CompoundCommand containing multiple RecordingCommands does not undo correctly [message #417108 is a reply to message #416664] |
Wed, 27 February 2008 09:08 |
PÃ¥l Stenslet
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi,
Thanks, I was not aware of ChangeCommand. Anyhow, I find that triggers also
significantly simplify the programming of our editing operations, so I
think I will stick with the transaction framework.
Regards,
Paul
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fopuul$f6u$1@build.eclipse.org...
> Hi, Paul,
>
> Yes, I thought we had done something to make RecordingCommands usable as
> triggers. I guess it's just the aggregation in a CompoundCommand for
> execution on the CommandStack that was overlooked and needs to be resolved
> on your bug.
>
> The programming model of the RecordingCommand is convenient, yes. That's
> why we provided it in the first place :-)
>
> BTW, did you know that the RecordingCommand seems to have inspired the
> core
> EMF component to provide a similar facility? If you don't need the rest
> of
> the transaction capability, have a look at the
> org.eclipse.emf.edit.command.ChangeCommand.
>
> cW
>
> Pål Stenslet wrote:
>
>> Hi, Christian
>>
>> Thanks for your comments.
>>
>> With the workaround mentioned in my bug report, I find RecordingCommands
>> most useful. FYI RecordingCommands work well as triggers and they mix
>> well
>> with
>> CompundCommands (and other Commands). We are using EMF in a non-eclipse
>> client. We started out without EMF transactions, but after migration to
>> EMF 2.3 we were finally able to isolate the EMF transaction support for
>> use outside Eclipse. The other people working on the project are very
>> happy with the simplified programming model provided by RecordingCommand.
>>
>> Regards,
>> Paul
>
> -----8<-----
|
|
|
| Re: CompoundCommand containing multiple RecordingCommands does not undo correctly [message #417132 is a reply to message #417108] |
Wed, 27 February 2008 13:49 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Paul,
I'm glad you're having success with transactions! I didn't intend, of
course, to discourage their use.
Thanks for your positive feed-back. I should be making progress on your
bug, soon.
cW
Pål Stenslet wrote:
> Hi,
>
> Thanks, I was not aware of ChangeCommand. Anyhow, I find that triggers
> also
> significantly simplify the programming of our editing operations, so I
> think I will stick with the transaction framework.
>
> Regards,
> Paul
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fopuul$f6u$1@build.eclipse.org...
>> Hi, Paul,
>>
>> Yes, I thought we had done something to make RecordingCommands usable as
>> triggers. I guess it's just the aggregation in a CompoundCommand for
>> execution on the CommandStack that was overlooked and needs to be
>> resolved on your bug.
>>
>> The programming model of the RecordingCommand is convenient, yes. That's
>> why we provided it in the first place :-)
>>
>> BTW, did you know that the RecordingCommand seems to have inspired the
>> core
>> EMF component to provide a similar facility? If you don't need the rest
>> of
>> the transaction capability, have a look at the
>> org.eclipse.emf.edit.command.ChangeCommand.
>>
>> cW
-----8<-----
|
|
|
Goto Forum:
Current Time: Thu Sep 19 00:58:22 GMT 2024
Powered by FUDForum. Page generated in 0.03801 seconds |
] 
Search
Help
Register
Login
Home
