Re: Action based undo or snapshot based undo?
Re: Action based undo or snapshot based undo?
- Subject: Re: Action based undo or snapshot based undo?
- From: Alexander Lamb <email@hidden>
- Date: Thu, 30 Jan 2003 08:58:27 +0100
Bill,
I think your book is excellent!
I don't have your book handy at the office so I will definitly have a look
to see where I misunderstood. My mistake is probably that I havn't yet
finished the book, and this for a rather bad reason: I worked on NeXT then
OpenStep since 1992 and I was even part of Professional Services in 1996 in
NY. I worked mostly with EOF and the time and undo managers where not used
the same way... So, you see, I *think* I know, so I tend to skip parts of
the text:-) My fault! (I am now also only doing a "pet project" in Coca, my
day job is managing a team doing WebObjects and Oracle in a healthcare
environment, so I have probably been brainwashed by Java over the last few
years).
Well, this being said, EOF does do snapshot based undo. I have no problem
with action based undo if it can be rendered as generic as it is in EOF.
Which means (as Greg also said) to have some kind of elegant way of
notifying of changes in objects so the UI can update accordingly.
NSNotification is the way, however it would be even nicer to have as in EOF,
the model to which you would simply connect UI elements from IB and tell
what kind of connexion it is!
Now, imagine a user action updates several attributes of the object model.
You would need to implement in the action method the user calls two things:
1. Reflect the action in the menu (undo action in your terms)
2. Setup an undo group
Indeed, if one user action updates several attributes (which each record an
undo action), a simple user undo will not get back far enough, hence the
undo group. Am I right here?
However, when you think of it, it could maybe even be a standard setup to
register an undo group at the begining of each event loop. The user always
want to undo what has been done in the event loop not only part of it!
I am only trying to find a way to avoid very similar code to end up at many
places when it could maybe be possible to setup some generic behavior. Maybe
even by defininf some kind of EOModel specifically tuned to Cocoa persistent
objects.
As someone else also stated, some times you may want to optimise undo and
when you start a large calculation, duplicate the object graph and discard
it if you undo.
Alexander
On 29.1.2003 21:19, "Bill Cheeseman" <email@hidden> wrote:
>
on 03-01-29 12:37 PM, Greg Titus at email@hidden wrote:
>
>
> On Tuesday, January 28, 2003, at 11:32 PM, Alexander Lamb wrote:
>
>
>
>> 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.
>
>
>
> I totally disagree with Bill here (sorry Bill), and I think that that
>
> is why you are running into problems.
>
>
>
> You should register the changes at the object level, but you should set
>
> the action name in the action methods.
>
>
Alexander, may I suggest that you misunderstood what I wrote in my book?
>
>
Greg is right, and in my book I take the same approach he describes. This is
>
what Apple's documentation recommends, too.
>
>
The operation that changes the data should be recorded at the model level,
>
typically in your model object's set accessor method. But you should set the
>
title of the Undo menu item in your controller's action method, for the
>
reasons you described: The Undo menu item's title should reflect the nature
>
of the user's activity, such as "Undo Choose Menu Item" or "Undo Click
>
Button", not the nature of the change to the underlying data. The point is
>
to remind the user of what he or she did, not what the computer did. The
>
easiest place to tell which action the user performed is in the action
>
method, because its 'sender' parameter is available to tell you whether it
>
was a menu item or a button.
>
>
Perhaps your confusion arose from the fact that my book refers both to an
>
"undo action" and to an "action method." They are two different things,
>
though closely related:
>
>
(1) The term "undo action" is used to describe the operation (or "action")
>
on the data, such as changing a Boolean variable from YES to NO. It is
>
recorded on the undo stack so it can be "played back" when the user later
>
chooses Edit > Undo. Yoy should record this "undo action" with the undo
>
manager in your model object's set accessor method because it relates to the
>
model object's data, as described at page 111 of my book.
>
>
(2) The term "action method" describes the method (typically in your window
>
controller) that is triggered when the user performs some action (or
>
"operation") while sitting at the computer, such as choosing a menu item or
>
clicking a button. You should set the new title for the undo menu item in
>
your "action method" because it relates to the nature of the user's
>
activity, as described at page 115 of my book.
>
>
One could argue that Apple's documentation is very precise, referring to
>
what I call an "undo action" as an "undo operation," while referring to the
>
user's activity as an "action." For example, the introduction to the
>
NSUndoManager class reference document currently says, "You register an
>
*undo operation* by specifying the object that's changing (or the owner of
>
that object), along with a method to invoke to revert its state, and the
>
arguments for that method." But the same document's description of the
>
'setActionName:' method says it "Sets the name of the *action* associated
>
with the Undo or Redo command to actionName." Personally, I think that's an
>
awful lot of meaning to try to hang on the difference between the words
>
"operation" and "action" -- especially in light of a Cocoa method like
>
'removeAllActions', which would have to be named 'removeAllOperations' to be
>
consistent.
>
>
It isn't often in Cocoa that you have to work your way past the terminology
>
to understand the concepts, but perhaps this is one of those rare times. If
>
you would point me to the passage in my book where you felt I was saying
>
something different than what I meant, I will consider putting some
>
clarification on the book's errata page.
>
>
--
>
>
Bill Cheeseman - email@hidden
>
Quechee Software, Quechee, Vermont, USA
>
http://www.quecheesoftware.com
>
>
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
>
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
>
Croquet Club of Vermont - http://members.valley.net/croquetvermont
>
_______________________________________________
>
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.
_______________________________________________
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.