Skip navigation.
 
mlRe: beyond MV and (one) C
FROM : Daniel Child
DATE : Fri Jan 18 21:09:04 2008

On Jan 13, 2008, at 1:35 PM, mmalc crawford wrote:

> Additional controllers come into play if you want to devolve 
> responsibility for managing a fairly self-contained subset of the 
> UI to a separate controller.  NSWindowController is perhaps the 
> "biggest granularity" example where rather than an NSDocument 
> instance being responsible for multiple windows it can devolve 
> responsibility to individual window controllers.  A window 
> controller might then devolve responsibility for managing, say, a 
> table view to an NSArray controller.  Or for a custom view you 
> might implement your own NSViewController. It's all up to you to 
> decide how you want to factor out the workload.


I think I understand why you might devolve responsibility to window 
controllers in a doc app. I don't see what they do in a non-doc app, 
however.

More importantly, how you get the window controllers working in the 
first place? The description of controller objects "owning" mediating 
controllers  (in "MVC Design Patterns") is totally abstract to me 
until I see an example of how this is done.

To test the idea, I created an app with two nibs:

MainMenu.nib -- contains WindowA and WindowB
WindowC.nib  -- contains WindowC

Each window has a button to reference the other two. (Open Window A, 
Open Window B, etc.)

MainMenu.nib has an instance of a (typical) Controller (subclass of 
NSObject) that has code for windows A and B.

WindowC.nib has an instance of a WindowCController that is a subclass 
of NSWindowController, and has code for the actions of Window C 
(openA and openB).

I can get WindowA to open WindowB, and vice versa, just fine. Both 
windows tie into the CentralController and use the standard target-
action paradigm. But this design is clearly a mess.

Using this is forcing me to copy code (openA, openB) into different 
controllers. Not a good idea.

Also, how will the different nibs know about each other? When I 
instantiate the WindowCController, there seems to be no recognition 
of the fact that I had declared an IBOutlet NSWindow *windowC or 
IBActions (openA, openB). In other words, the instantiated subclass 
of NSWindowController does not behave like a regular controller in 
terms of the target-action paradigm.

I think my questions may be as much practical as theoretical. How do 
you literally hook up window controllers / open/load separate nibs. 
And do I have to mess around with File's Owner at this point (i.e. in 
WindowC.nib)?

Related mailsAuthorDate
mlbeyond MV and (one) C Daniel Child Jan 13, 17:59
mlRe: beyond MV and (one) C mmalc crawford Jan 13, 19:35
mlRe: beyond MV and (one) C mmalc crawford Jan 13, 20:24
mlRe: beyond MV and (one) C Daniel Child Jan 18, 21:09
mlRe: beyond MV and (one) C Ken Thomases Jan 20, 11:45
mlRe: beyond MV and (one) C mmalc crawford Jan 20, 11:58
mlRe: beyond MV and (one) C Ken Thomases Jan 20, 14:21
mlRe: beyond MV and (one) C Daniel Child Jan 21, 05:57