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

[Robert Brewer]

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
MIS
Amor Ministries
fumanchu at amor.org