Action based undo or snapshot based undo?
Action based undo or snapshot based undo?
- Subject: Action based undo or snapshot based undo?
- From: Alexander Lamb <email@hidden>
- Date: Wed, 29 Jan 2003 08:32:48 +0100
Hello,
As I understood, the NSUndoManager is based on the idea of recording a
series of actions needed if the user wants to undo what he just did.
In Bill Cheeseman's book, he recommands recording those actions in the
action methods rather than at the object level, because it reflects
more closely what the user is doing and allows to customize the undo
for an action that may involve several changes on objects attributes.
Now, I am having trouble with this whole concept for a few reasons:
Firstly, registering undo everywhere a user may hit an action can
become rather complex because of the number of places where this might
happen. For example: the data source of a NSTableView. How can you
implement the undo in the data source method setting the new cell
value? Not very elegant!
Another issue is calculations. Not everything can be undone by actions!
Imagine I have an object graph on which I need to perform a
calculation. Lots of attributes get changed and then I need to undo. I
can't register the contrary of an optimisation calculation (imagine I
am optimising a schedule for example). The only way here would be to
duplicate the whole object graph and upon an undo discard the new
object graph.
So, (and you will see my roots in EOF here:-), why not implement a
snapshot based undo. Like the EOControl layer of EOF? No need for the
same complexity since you really need only one editing context and no
SQL generation. Just the registration of attributes changes. Now, the
nice thing about that is that you could register in one snapshot all
the attributes that have changed in one event loop. Therefore an undo
is just a question of going back one set of attributes. And... it works
also when objects are changed "in the background" from a calculation or
a network access, and... last but not least: it could allow
notification of change in a standard way and allow automatic update of
UI elements (like the EOInterface layer in EOF).
So... why not use the Object layer and Interface layer of EOF:-) and
forget about the object persitence part?
So, my questions:
- Is there something being developped going that direction?
- Is the interface and object layer of EOF considered EOL (e.g. dead or
can it be used... in Objective-C)?
- Am I missing totally something here?
Thanks,
Alex
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.