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)?
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 mails | Author | Date |
|---|---|---|
| Daniel Child | Jan 13, 17:59 | |
| mmalc crawford | Jan 13, 19:35 | |
| mmalc crawford | Jan 13, 20:24 | |
| Daniel Child | Jan 18, 21:09 | |
| Ken Thomases | Jan 20, 11:45 | |
| mmalc crawford | Jan 20, 11:58 | |
| Ken Thomases | Jan 20, 14:21 | |
| Daniel Child | Jan 21, 05:57 |






Cocoa mail archive

