| AbstractEMFOperation vs Command [message #522416] |
Mon, 22 March 2010 15:21  |
|
Hi,
In order to modify EMF resources, I can use AbstractEMFOperation or org.eclipse.emf.common.Command
I'm wondering:
- what is the real difference between each of us?
- In which case should I use one instead of another?
It seems that Command are registered with WorkspaceCommandStackImpl$1 context. So will it be in-memory during all time that the program is running? How can I set a limit to this stack context?
Any hints or references on these class are welcomed.
Regards,
Aurélien Pupier - Red Hat
Senior Software Engineer in Fuse Tooling team
|
|
|
| Re: AbstractEMFOperation vs Command [message #522472 is a reply to message #522416] |
Mon, 22 March 2010 17:49  |
|
Hi, Aurelien,
I shall start by assuming that you already need the concurrency,
validation, and rollback support provided by the EMF Transaction
framework, because this is the only context in which
AbstractEMFOperation makes sense.
Given that, the primary distinction between AbstractEMFOperation and
Command is in integration with the Eclipse Workbench's
IOperationHistory. This enables a more complex "undo stack" model than
the single linear stack of the EMF CommandStack. The IUndoContexts that
tag IUndoableOperations project a single undo history history onto any
number of intersecting "undo stacks." An editor presents one of these
stacks in its Undo/Redo menu actions by selecting its contexts.
One motivation for integrating with the operation history is
demonstrated by GMF: the ability to let multiple editor instances work
on a shared model (in a shared TransactionalEditingDomain), each
maintaining their own view of the undo history, but still accounting for
dependent changes made in the other editors.
HTH,
Christian
On 22/03/10 11:21 AM, Aurelien Pupier wrote:
> Hi,
>
> In order to modify EMF resources, I can use AbstractEMFOperation or
> org.eclipse.emf.common.Command
>
> I'm wondering:
> - what is the real difference between each of us?
> - In which case should I use one instead of another?
>
> It seems that Command are registered with WorkspaceCommandStackImpl$1
> context. So will it be in-memory during all time that the program is
> running? How can I set a limit to this stack context?
>
> Any hints or references on these class are welcomed.
>
> Regards,
|
|
|
Powered by
FUDForum. Page generated in 0.02726 seconds
] 
Search
Help
Register
Login
Home
