A DESCRIPTION OF THE REQUEST :
The current framework -- consisting of UndoableEdit, AbstractUndoableEdit, CompoundEdit, UndoManager -- is very confusing to new users and is not intuitive.

Some examples:

- UndoableEdit introduces the concept of "alive", CompoundEdit introduces the concept of "inProgress", UndoManager introduces the concept of "indexToAdd".

- It is difficult to know what behavior to expect from end(), canUndo(), canRedo() because they layer on top of methods of the same name in the superclass but with different behavior. Depending upon the state of the object, these methods will behave differently and it is difficult to keep track of what is what.

- The behavior of addEdit(), replaceEdit() is unintuitive and I found myself rereading the docs five times and finally resorting to viewing the source-code before I understood the behavior.

Another problem is that the tutorial for this framework is too simple and assumes we're trying to add support for undo/redo for Swing documents, which is not always the case. The undo framework is meant to be a generic undo framework, not specific to Document. The tutorial should give examples of how to write an UndoableEdit task, keep track of changes, undo and redo them, etc.

JUSTIFICATION :
Ease of use

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Refactor framework with more cohesive methods that behavior in a predictable manner. Different methods with the same name in different layers should not behavior differently.

I suggest using a single class (say "UndoableEdit") and allow hierarchical nesting of actions such that a single edit can consist of multiple sub-edits and do away with the concept of "significant edits" by folding them as sub-edits of a higher-level edit. You would then not need the concept of CompoundEdit as all edits would support this.

Please focus on providing a very clean, intuitive and cohesive API!
###@###.### 2005-1-11 06:13:24 GMT