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.<br>You can read a little bit about this in the Command pattern documented in the GOF<br>
<br>Bye,<br>Hernan.<br><br><div class="gmail_quote">On Wed, Apr 16, 2008 at 1:06 AM, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
On 15-Apr-08, at 8:46 PM, Colin Putney wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
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.<br>
</blockquote></div>
That's pretty much what we did in Sophie. It's non-trivial but then the problem domain is non-trivial.<br>
<br>
tim<br><font color="#888888">
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
A sad tale that brings a lump to the eye and a tear to the throat.<br>
<br>
<br>
<br>
</font></blockquote></div><br>