Bug 314250

Comment 1 Ansgar Radermacher 2010-06-01 17:04:24 EDT

In order to start the discussion

Need to have:
  - something like RecordingCommand, i.e. undo should be automatic
  - possibilty to create nested commands (compounds), in order to have a single undo/redo for a set of commands

- Currently used (please check, if true)
    - RecordingCommand (org.eclipse.emf.transaction)
        domain = EditorUtils.getTransactionalEditingDomain();
        stack = domain.getCommandStack ();
        stack.execute ( new RecordingCommand (...) ..., "label", "description");
        User has to implement: "void doExecute()"

        Used by ModelExplorer (only?)

        Pro: simple to use
            - Supports compounds
        Cons:
            - Command Label/descrip is not shown (only "Undo/Redo"), a bug of
                Edit menu wihch could be fixed?
            - No progress monitor (good for long running model modifications. Although rarely used, might be important in case of complex model transformations (which take a bit of time)

    - AbstractTransactionalCommand (org.eclipse.gmf.runtime.emf.commands.core.command)
        IOperationHistory history = OperationHistoryFactory.getOperationHistory();
        history.execute ( new AbstractTransactionalCommand (domain, "label", Collections.EMPTY_LIST) {
        User has to implement
            "CommandResult doExecuteWithResult (IProgressMonitor pm, IAdaptable info)"

        Pro:
            - Command label is shown in Edit menu
        Cons:
            - Slightly more difficult to use (need to return CommandResult, can always return null?)
        Open: supports compounts?

Comment 2 Cedric Dumoulin 2010-06-15 09:07:15 EDT

It is possible to let the EditingDomain's CommandStack register its operations on the IOperationHistory:
Use a org.eclipse.emf.workspace.WorkspaceEditingDomainFactory.

This solves some problems, but doesn't free us to clarify how Papyrus commands should be executed.

Comment 3 Remi Schnekenburger 2010-06-16 12:37:17 EDT

In the property view framework, I use the OperationHistory framework. It seems that since your last modification, the undo/redo works for me.
Sounds great!

Comment 4 Cedric Dumoulin 2010-06-17 04:51:39 EDT

Fine.
When the IOperationHistory is used directly, we should take care to use transactional commands for read and write.
Transactional Commands are subclasses of the following:
- RecordingCommand
- AbstractEMFOperation

Comment 5 Cedric Dumoulin 2011-01-19 09:41:04 EST

A Draft document about History management, commands and undo/redo is available :
/trunk/doc/DevelopperDocuments/architecture/commandExecution.doc
and a uml model of code reverse:
/trunk/doc/DevelopperDocuments//architecture/CommandStackFramework.di
/trunk/doc/DevelopperDocuments//architecture/CommandStackFramework.notation
/trunk/doc/DevelopperDocuments//architecture/CommandStackFramework.uml

Comment 6 Toni Siljamäki 2013-10-09 08:49:43 EDT

No activity on this one for >2.5 years.
Still valid, or should it be closed?

Comment 7 Camille Letavernier 2014-03-25 15:22:13 EDT

Current state (Luna > M6):

- For ICommands executed in the DiagramCommandStack, the isDirty/isUndoable state is computed automatically (Depending on the modified resources, if any, and on the INonDirtying interface implementation)
- For IOperations executed in the OperationHistory, the isDirty state is computed automatically (Depending on the modified resources, if any)
- For EMF Commands executed in the EditingDomain CommandStack, the command is always dirtying the editor. The isUndoable state depends on the Command#canUndo implementation (Which should probably always be true in this case).

For detailed technical information, See Bug 429239 (Non-dirtying transactions), Bug 421411 (Non-dirtying commands), Bug 323802 (Non-dirtying Unsafe transactions), Bug 402525 (Nested commands/command stack)