Re: Where does Undo fit in MVC
Re: Where does Undo fit in MVC
- Subject: Re: Where does Undo fit in MVC
- From: Bill Cheeseman <email@hidden>
- Date: Sat, 23 Apr 2005 08:41:52 -0400
on 2005-04-23 5:28 AM, Marcus Roberts at email@hidden wrote:
> I'm currently confused though as to where undo management should go.
> The cocoa recipies have many calls to the undo manager in the model
> itself, with additional undo management in the window controller.
> This feels a little wrong, as I would expect the model data to not
> know about the document or its undo manager. The Hillegass book in
> Chapter 7 moves the undo code into the document object, and uses KVO
> to determine when the model has changed. This feels more in line with
> MVC.
The Vermont Recipes approach is pretty typical and, I think, theoretically
correct, at least in the pre-bindings world.
Undo and redo typically are model-level operations, because they actually
change the underlying data. In an MVC context, at least in any reasonably
complex application, the document object shouldn't know about the details of
the model, but should instead ask the model for that information or tell the
model to make changes to that information. By the same token, as you note,
the model object shouldn't know about the document. Because undo and redo
directly affect the model, the instructions to the undo manager to record or
register undo and redo actions should therefore be at the model level.
You'll notice, in this regard, that the Vermont Recipes document object is
very small and simple, with all of the model functionality offloaded to
separate model objects. All the document really needs to know is how to read
and write model objects, which it can do without knowing anything about
them.
The part of undo and redo that should be in the controller layer under MVC
is the setting of the undo and redo menu item titles. This is because,
according to the Human Interface Guidelines, the menu item titles should be
specific to the nature of the user interface action that changed the data,
not to the change in the data itself. In many circumstances an application
may have multiple user interface ways to change the data, even though each
operation makes exactly the same change to the underlying data. You will
often want to use different undo or redo menu item titles in that situation.
I think your confusion arises from a misconception of the role of the undo
manager itself in the MVC context. Think of it as a controller. Like any
controller, it mediates between the view and the data. The NSUndoManager
methods for recording and registering undo actions control the model layer,
and the NSUndoManager methods for setting the action name control the view
layer. As with all controllers under MVC, the undo manager must know about
both the model and the view.
> But from what I've read on the Apple site, Core Data will provide the
> undo/redo management, down in the model.
Can't really talk in detail about that until Friday. But in general, in my
still weak understanding of bindings, they seem to introduce considerable
confusion regarding the traditional MVC distinctions with regard to undo and
redo.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden