[PEAK] Commands, Actions, Undo/Redo, and transactions

Robert Brewer fumanchu at amor.org
Wed Jul 28 17:31:00 EDT 2004

Phillip J. Eby wrote:
> Error handling is going to be interesting for IAction and 
> IActionGroup 
> implementors, because an action group *must* be undone or redone 
> completely.  If a contained action's undo() or redo() fails, 
> the entire 
> workspace must be considered *unstable* and *unusable*.  (At 
> a minimum, all 
> action-related functions should be disabled, especially 
> commitAction/rollbackAction.)  If the workspace is associated with a 
> transaction, the transaction must also be marked as corrupt.  
> These rules 
> are harsh, but failure really shouldn't be an option here.

Absolutely correct. Better to be harsh during the transaction than
afterward. :)

> In practice, 
> most undo()/redo() methods will be: 1) fairly trivial, and 2) 
> supplied by 
> PEAK, which means they'll be tested by many PEAK users and 
> unlikely to fail 
> unless the workspace really *is* corrupted in some way.  
> (Action classes in 
> general are part of the mapping layer, not client code or the 
> abstract 
> model, so few developers will have to deal with their 
> trickiness directly.)
> Whew!  I think that about covers it.  I think this actually 
> constitutes a 
> "best of breed" API, in that it covers scenarios ranging from object 
> prevalence, to GUIs with undo/redo, to "typical" database 
> applications, to 
> esoteric nested transaction needs.

The breadth and depth of your ideas posted here are truly amazing.
Excellent work!

Robert Brewer
Amor Ministries
fumanchu at amor.org

More information about the PEAK mailing list