| What is the advantage of use AbstractTransactionalComman ? [message #8216] |
Mon, 07 August 2006 07:07  |
Eclipse User |
|
|
|
What is the advantage of use of SetValueCommand over the use of SetCommand
executing the last one in WorkspaceCommandStackImpl? While being executed
in WorkspaceCommandStackImpl SetCommand will be first wrapped into
EMFOperationCommand and after that executed in the IOperationHistory. So
it seems to have the same effect as executing SetValueCommand in the
IOperationHistory.
Actually, I would like to clarify a few questions concerning different
commands in GMF:
- when and why should we execute command in CommandStack ?
- why execution use of org.eclipse.emf.common.command.Command descendants
is dicouraged in GMF and all code mostly uses AbstractTransactionalCommand
descendants?
|
|
|
| Re: What is the advantage of use AbstractTransactionalComman ? [message #10055 is a reply to message #8216] |
Tue, 08 August 2006 13:48  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Yury,
The WorkspaceCommandStackImpl implements a single, linear undo stack using
the operation history. It is intended to provide the same behaviour as the
EMF CommandStack.
However, using AbstractEMFOperations (or GMF's
AbstractTransactionalCommands) with an operation history (not using the
WorkspaceCommandStackImpl), you can implement more interesting undo models.
For example, you can have independent undo/redo stacks for different
Resources in the same ResourceSet, if these resources are not connected.
Using EMF's CommandStack, you would actually need a separate ResourceSet
and EditingDomain for each resource.
To answer your first question: in a GMF application, you should probably
never execute commands in a CommandStack, because it will not be worth the
effort of coordinating the IUndoContexts applied to these commands and your
GMF AbstractTransactionalCommands to ensure that the Undo/Redo menus make
sense.
HTH,
Christian
Yury wrote:
> What is the advantage of use of SetValueCommand over the use of SetCommand
> executing the last one in WorkspaceCommandStackImpl? While being executed
> in WorkspaceCommandStackImpl SetCommand will be first wrapped into
> EMFOperationCommand and after that executed in the IOperationHistory. So
> it seems to have the same effect as executing SetValueCommand in the
> IOperationHistory.
>
> Actually, I would like to clarify a few questions concerning different
> commands in GMF:
>
> - when and why should we execute command in CommandStack ?
>
> - why execution use of org.eclipse.emf.common.command.Command descendants
> is dicouraged in GMF and all code mostly uses AbstractTransactionalCommand
> descendants?
|
|
|
| Re: What is the advantage of use AbstractTransactionalComman ? [message #11581 is a reply to message #10055] |
Wed, 09 August 2006 06:09 |
| Eclipse User |
|
|
|
Hi Christian,
Thanks for your reply. I still have some questions.
> The WorkspaceCommandStackImpl implements a single, linear undo stack using
> the operation history. It is intended to provide the same behaviour as the
> EMF CommandStack.
> However, using AbstractEMFOperations (or GMF's
> AbstractTransactionalCommands) with an operation history (not using the
> WorkspaceCommandStackImpl), you can implement more interesting undo models.
> For example, you can have independent undo/redo stacks for different
> Resources in the same ResourceSet, if these resources are not connected.
> Using EMF's CommandStack, you would actually need a separate ResourceSet
> and EditingDomain for each resource.
At present I need single execution stack for my application.
IOperationHistory and OperationHistoryFactory suits fine for this. But
working with diagram editor in general I do not know what kind of
CommandStack it is using and if that stack is backed by global
IOperationHistory or not. At the same time I need to show some feedback
when the command stack changes. Currently my application listens
CommandStack that can be retrieved from the EditingDomain of
DiagramEditor. If all modifications are performed using the CommandStack
then I always know when to show feedback. If I execute a sort of
AbstractEMFOperation in the global operation history the CommandStack does
not trigger any events. If I understand correctly you suggest to support
custom mapping from Resource to IOperationHistory instance (like the
mapping Resource->ResourceSet->EditingDomain->CommandStack). In my case it
is trivial:
Resource->global IOperationHistory. Everyone who modifies my model should use
global history and feedback provider would listen to the IOperationHistory not
to CommandStack. Am I right?
> To answer your first question: in a GMF application, you should probably
> never execute commands in a CommandStack, because it will not be worth the
> effort of coordinating the IUndoContexts applied to these commands and your
> GMF AbstractTransactionalCommands to ensure that the Undo/Redo menus make
> sense.
So if I want to implement a custom command which makes some changes with
my EMF model I have to create a command inherited form
AbstractEMFOperation and put all logic within it. Afterwards when I
execute it in IOperationHistory I will get Undo/Redo functionality for
free. Is it true?
Yury
|
|
|
| Re: What is the advantage of use AbstractTransactionalComman ? [message #13269 is a reply to message #11581] |
Wed, 09 August 2006 14:55 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Yury,
See some responses, in-line.
HTH,
Christian
Yury wrote:
> Hi Christian,
>
> Thanks for your reply. I still have some questions.
>
<snip>
> At present I need single execution stack for my application.
> IOperationHistory and OperationHistoryFactory suits fine for this. But
> working with diagram editor in general I do not know what kind of
> CommandStack it is using and if that stack is backed by global
> IOperationHistory or not. At the same time I need to show some feedback
> when the command stack changes. Currently my application listens
> CommandStack that can be retrieved from the EditingDomain of
> DiagramEditor. If all modifications are performed using the CommandStack
> then I always know when to show feedback. If I execute a sort of
> AbstractEMFOperation in the global operation history the CommandStack does
> not trigger any events. If I understand correctly you suggest to support
> custom mapping from Resource to IOperationHistory instance (like the
> mapping Resource->ResourceSet->EditingDomain->CommandStack). In my case it
> is trivial:
> Resource->global IOperationHistory. Everyone who modifies my model should
> use global history and feedback provider would listen to the
> IOperationHistory not to CommandStack. Am I right?
Yes. In a GMF-based application, it will be better to listen to the
IOperationHistory, because that will capture all changes, including those
performed via the CommandStack. GMF's own UI actions will always execute
IUndoableOperations on the history, never Commands on the CommandStack.
>
<snip>
> So if I want to implement a custom command which makes some changes with
> my EMF model I have to create a command inherited form
> AbstractEMFOperation and put all logic within it. Afterwards when I
> execute it in IOperationHistory I will get Undo/Redo functionality for
> free. Is it true?
That is one option (and, yes, you will get Undo/Redo for free). Another
option, which is especially useful if you want to share code between
GMF-based and non-GMF-based applications, is to create your custom commands
as EMF Commands (AbstractCommand) and wrap them in EMFCommandOperations to
execute on the IOperationHistory, yourself. This gives you the best of
both worlds :-)
>
> Yury
|
|
|
| Re: What is the advantage of use AbstractTransactionalComman ? [message #13297 is a reply to message #13269] |
Wed, 09 August 2006 14:59 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Christian W. Damus wrote:
<snip>
> Yes. In a GMF-based application, it will be better to listen to the
> IOperationHistory, because that will capture all changes, including those
> performed via the CommandStack. GMF's own UI actions will always execute
> IUndoableOperations on the history, never Commands on the CommandStack.
Sorry, I should correct the above statement: the UI actions provided by the
GMF *runtime* will always execute IUndoableOperations on the history.
Christian
<snip>
|
|
|
Powered by
FUDForum. Page generated in 0.05047 seconds
Home