We did something similar with our financial application, therefore all
financial transactions can be canceled and all their impact (from
registration to accounting) can be undone.
You can read a little bit about this in the Command pattern documented in
the GOF

Bye,
Hernan.

On Wed, Apr 16, 2008 at 1:06 AM, tim Rowledge <tim at rowledge.org> wrote:

>
> On 15-Apr-08, at 8:46 PM, Colin Putney wrote:
>
> >
> >
> > The usual way to do this is to have all your undoable units of work be
> > implemented by "command" objects that know how to perform a specific action.
> > Then when the user does something undoable, you create a command, execute
> > it, then push it on the undo stack. To undo you can either have the command
> > know how to undo its self, or have it create an "inverse" command. This kind
> > of thing works pretty well, and it can be extended with other features like
> > redo, logging, journal-and-snapshot persistence etc.
> >
> That's pretty much what we did in Sophie. It's non-trivial but then the
> problem domain is non-trivial.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> A sad tale that brings a lump to the eye and a tear to the throat.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080417/ac618ab2/attachment.htm