Re: NSDocument as controller vs. as model
Re: NSDocument as controller vs. as model
- Subject: Re: NSDocument as controller vs. as model
- From: Bill Cheeseman <email@hidden>
- Date: Mon, 01 Oct 2001 15:18:56 -0400
on 10/1/01 2:07 PM, Brian Hook at email@hidden wrote:
>
> [mailto:email@hidden] On Behalf Of Bill Cheeseman
>
>
> Somewhere in the documentation you will see a suggestion that
>
> it's OK to use NSDocument as both model and controller in
>
> very simple applications. But if you anticipate having even a
>
> moderately complex or extensive data structure, my feeling is
>
> that it's best to leave NSDocument as a pure controller and
>
> create separate object(s) for your model. It should make
>
> extensibility easier. That's how I did it in Vermont Recipes,
>
> and it's working out pretty well.
>
>
That's pretty much what I thought. So in reality, the MVC paradigm
>
expands into:
>
>
application delegate (the "meta controller"?)
>
document controller controller (NSDocumentController...ugh, the
>
nomenclature is ghastly)
>
document controller (NSDocument)
>
document/model (app specific)
>
window controller (NSWindowController or subclass)
>
windows (NSWindow/Panel/etc.)
>
>
Then you would typically have a MainMenu.nib with no window, just the
>
application's delegate as File's Owner (?). Then auxiliary NIBs will
>
store specific windows and their various controllers, e.g. a
>
Document.nib that would have a document window and an NSDocument as the
>
File's Owner?
>
>
Does this sound right? Sorry if I'm sounding confused, but this is a
>
lot of information to grasp at once, especially for those of us crippled
>
with a C++/MFC background =)
Yes.
Except that I use NSWindowController as File's Owner for my document's main
window nib file. The documentation suggests you can use either
NSWindowController or NSDocument as its File's Owner, but I'm not clear what
factors should be considered in making a choice. When I started, the
documentation gave me a vague impression that using NSWindowController would
eventually leave me with greater flexibility in a large application, and I
haven't (yet) regretted the choice.
I haven't monkeyed with MainMenu.nib enough to know who is its File's Owner.
So far, I have had no need of an application delegate, although one will
certainly be needed if I decide to do certain things that fall in
NSApplication's department.
Because I use NSWindowController as File's Owner, and separate objects for
data, my NSDocument subclass is extremely small and hardly ever needs to be
touched -- mostly just to modify storage routines when I add another model
object.
My subclass of NSWindowController, however, is huge, and getting larger with
every new user control. I'm starting to look at ways to organize it or,
better yet, to break it into smaller pieces. I am toying with the idea of
setting up my NSWindowController subclass as a tiny super-controller, or
"dispatcher," with a separate "sub-controller" for each control in the
window, or for each group of controls related to a specific data set. Maybe
it would be best to have a separate sub-controller for all controls related
to a particular model object; i.e., a one-to-one relationship between each
model object and the window subcontroller that handles interface elements
for that model object's data. But I haven't even begun to think this
through, and I realize that there might not always be a one-to-one
correspondence.
I often hear NextStep veterans grousing about how much tedious code has to
be written to take care of routine accessor methods, action methods, update
methods and so on for each user control. So the idea behind a sub-controller
for each control or group of controls would be to allow the use of a highly
routinized structure for each, one that would lend itself to development of
a standard fill-in-the-blanks template.
I would welcome reactions to this notion from more experienced developers.
--
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