Previous |
The Bean Works command processing mechanism provides built-in support for serially undoable commands, that is, commands that the user can undo (and redo) in the same order in which they were originally executed. This is supported automatically if your commands fully implement the interfaces provided by the basic command classmethods that the framework calls when the command is done, undone, and redone.
The framework provides a default command processor that uses a command log to enable serially undoable commands. The default command processor is created by the component controller automatically at runtime. When the user initiates a command-based action, the controller calls the command processor to add the command to the log and execute the command.
The command processor maintains this log until something happens that causes the commands to be committed, for example, saving the document. This means that at any point during the session, the user can undo the command just executed, redo the command just undone, or execute a new command. New commands are added to the log in the position at which they are executed.
This figure, for example, shows a possible command log scenario.
The user has executed commands one through five, and then undone commands five and four, in that order. If the user issues a new command, it is added to the log at the position between commands three and four. The user at this point can also undo command three, or redo command four. The insertion point for new commands moves as the user does, undoes, and redoes commands
Note that you can also create commands that are not serially undoable. These commands can be of two types:
See Bean Works Architecture for information on the Java classes that define and implement commands and the command processor. You can implement the command processor interface yourself if you want to design your own command processing mechanism.
Copyright ©
Taligent, Inc. 1996 - 1997.
Copyright © IBM Corporation 1996 - 1997.
All Rights Reserved.