Re: Action based undo or snapshot based undo? Summary!
Re: Action based undo or snapshot based undo? Summary!
- Subject: Re: Action based undo or snapshot based undo? Summary!
- From: Alexander Lamb <email@hidden>
- Date: Thu, 06 Feb 2003 12:10:35 +0100
Bill, Greg and list,
Sorry for the late reply.
To answer directly to Bill about what caused confusion between the
ActionName to update the menus and the InvocationTarget to actually record
the undo.
Well, page 115 paragraph 6.2, the text starting with "The documentation
recommends that the setActionName: method be invoked in an action
method...". When reading this by bits and pieces and additionally, coming
from WebObjects where you have a lot of "key-value coding", you can
mistakenly take this for the actual action that will be recorded for the
undo.
However, it is my fault, as you said very well, the methods (lets not call
them actions:-) are registered at the model level.
But may I suggest adding one thing in the undo chapter. And it is Greg who
pointed it out (and it is very clearly stated in the documentation BTW). It
is the fact by default the event loop creates an undo group at the begining
of the loop. Therefore, even if several attributes are changed during the
event, they will be all undone by the group upon calling undo.
Since in the same chapter you speak about keeping the interface in synch, I
may add a comment for page 117, where you start by "There are at least two
available techniques... [to solve the problem of updating the UI]".
I must say that this whole paragraphe is not obvious to the casual reader
and I would suggest sticking to the notifications. Indeed, I feel it is not
only the simplest in terms of elegance of the code but also in terms of
power and functionality. I don't really see why you would want to use
another technique!
However, I think we could go further in the notification of change patterns.
Firstly, the post notification and the undo management are so "generic" in
the model, why not suggest having a generic superclass to handle those
things (like EOGenericRecord in EOF in a way)? Then, the notifications could
become more standard and could be all named "attribute update" for example
and the object passed with the notification could contain: the document, the
object being modified, the attribute name.
And... To make it even more generic, create an association class that is
instantiated for each UI object that needs to either be updated or that
changes the value of an object (again, more or less on the model of EOF).
This association objects listen to "attribute update" and decide if they
need to update the given UI object they monitor. In that way, the controler
code becomes even simpler since you don't need to listen to notifications,
but simply create association objects upon initialisation. To go even
further, as in EOF (my obsession as you can see:-), have the associations
classes as a palette in IB. Since there is no EOModel, simply have the
inspector of the association display a text field where the name of the
attribute would be entered.
Does this make sense?
Alexander
_______________________________________________
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.