IOperationHistory tracks a history of operations that can be undone or redone. Operations are added to the history once they have been initially executed. Clients may choose whether to have the operations history perform the initial execution or to simply add an already-executed operation to the history.
Once operations are added to the history, the methods {@link #canRedo(IUndoContext)} and {@link #canUndo(IUndoContext)} are used todetermine whether there is an operation available for undo and redo in a given undo context. The context-based protocol implies that there is only one operation that can be undone or redone at a given time in a given context. This is typical of a linear undo model, when only the most recently executed operation is available for undo. When this protocol is used, a linear model is enforced by the history.
It is up to clients to determine how to maintain a history that is invalid or stale. For example, when the most recent operation for a context cannot be performed, clients may wish to dispose the history for that context.
Additional protocol allows direct undo and redo of a specified operation, regardless of its position in the history. When a more flexible undo model is supported, these methods can be implemented to undo and redo directly specified operations. If an implementer of IOperationHistory does not allow direct undo and redo, these methods can return a status indicating that it is not allowed.
Listeners ( {@link IOperationHistoryListener}) can listen for notifications about changes in the history (operations added or removed), and for notification before and after any operation is executed, undone or redone. Notification of operation execution only occurs when clients direct the history to execute the operation. If the operation is added after it is executed, there can be no notification of its execution.
{@link IOperationApprover} defines an interface for approving an undo or redobefore it occurs. This is useful for injecting policy-decisions into the undo model - whether direct undo and redo are supported, or warning the user about certain kinds of operations. It can also be used when clients maintain state related to an operation and need to determine whether an undo or redo will cause any conflicts with their local state.
@since 3.1