Re: windowcontroller neccessary?
Re: windowcontroller neccessary?
- Subject: Re: windowcontroller neccessary?
- From: Mike Ferris <email@hidden>
- Date: Mon, 13 Jan 2003 09:52:53 -0800
From: Mike Ferris <email@hidden>
If you are using NSDocument then the document windows will always
have a windowController. For non-document windows, you can do what
you like, but NSWindowController is a really good class to start with
for your File's Owner.
I prefer allowing an NSDocument subclass to own a document's primary
nib file. I think a document instance should own and load a single nib
file to initialize an entire document just as an application instance
owns and loads a single nib file to initialize an entire application.
Even if you use the simpler setup where the NSDocument is the nib file
owner (as in the doc-based app template project), NSDocument uses an
NSWindowController behind the scenes to handle the nib file.
Also, note that if you will ever have any of the following situations,
you will ultimately want to do a separate NSWindowController subclass
(or several):
- Your documents will support multiple views, for example if the
user wants to have one window zoomed in and another showing actual size
of the same document.
- Your document needs several different windows to represent it,
for example a CAD program that has windows for front, side, top, and
rendered views (this could probably be done without custom
NSWindowControllers, but it is easiest to have a window controller per
window, usually.)
- Your document is complex enough to justify factoring it into
model-handling and view-handling logic just for the organizational
advantages.
Personally, I always assume I might need at least one of these
eventually, and the first thing I do when creating a new doc-based app
is flip it around to use an NSWindowController subclass as the nib
owner. Doing this initially is easier than doing it later when you've
got a lot of code written and then find you need the subclass.
From: matt neuburg <email@hidden>
Also NSWindowController is notified when its window loads. m.
A nib instantiated, nib-connected window-delegate would also get
notified when its window finished loading: see awakeFromNib.
I tend to avoid subclassing an AppKit object unless I will
specifically modify its existing responsibilities. In your case an
NSWindowController does imply some control over its window, so
subclassing to handle delegate messages does make some sense.
I would recommend against using window controllers as view
controllers. Two primary reasons: views may someday move to a new
window or a separate nib, and NSWindowController has no inherent
responsibility for your window's contents (although, some Cocoa
documentation and books recommend/use NSWindowController subclasses).
Some AppKit classes are meant to be subclassed and some are not.
NSDocument and NSWindowController are prime examples of objects meant
to be subclassed. NSWindow might be an example of one that is not
(which does not mean that you can't subclass it, but rather that you
rarely should need to).
NSWindowController is a really good choice to use for a nib file owner.
That is what it is meant for. It is always used for document windows
and it is a good class to use for controllers of other windows too.
And it can provide a reasonable starting point for subclassing to
develop a generic "view controller" object that owns a view, instead of
a window (as has been discussed here recently).
Mike
_______________________________________________
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.