• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: beyond MV and (one) C
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: beyond MV and (one) C


  • Subject: Re: beyond MV and (one) C
  • From: Daniel Child <email@hidden>
  • Date: Fri, 18 Jan 2008 15:09:04 -0500


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)?
_______________________________________________


Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: beyond MV and (one) C
      • From: Ken Thomases <email@hidden>
References: 
 >beyond MV and (one) C (From: Daniel Child <email@hidden>)
 >Re: beyond MV and (one) C (From: mmalc crawford <email@hidden>)

  • Prev by Date: Re: Accepting non-file drags in the Dock
  • Next by Date: Re: Starting an alert sheet from an NSWindowController that owns a user-editable sheet
  • Previous by thread: Re: beyond MV and (one) C
  • Next by thread: Re: beyond MV and (one) C
  • Index(es):
    • Date
    • Thread