• 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
NSController as controller instead of gateway
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NSController as controller instead of gateway


  • Subject: NSController as controller instead of gateway
  • From: daniel <email@hidden>
  • Date: Sun, 27 Feb 2005 12:17:31 -0800

I'm late to the bindings party. Hopefully this hasn't been discussed already. (Actually, hopefully it has been, and I can be sent on my merry way only a little bit embarrassed :) )

Most of the bindings examples use NSController as a "gateway" controller to an app-specific (old-style) controller. Why isn't there more emphasis on using NSController to interface directly with the model? Is this because a degree of "making up for bindings shortcomings" is anticipated, and the only/best place to do that would be in the app's custom controller? If so, why not make the app's controller a subclass of NSController? Why do I keep seeing pairs of blue and green boxes in IB? Most linkage seems to look like this:

Model <-> CustomController <-> NSController <-> View

I'm particularly interested in how to best apply bindings to a custom view whose UI is represented in a nib file. The emphasis on "wrapping a controller" is less offensive to me for high-level objects like NSDocument, but for lower level objects with their own bindings, it seems like it could cause a lot of bloating.

Let's say I have a document whose model includes hundreds of "Things". Each thing has a corresponding UI view defined in a ThingView nib file. In the old world, the ThingView nib's owner might be a ThingViewController, and the document would instantiate and keep track of ThingViewControllers as necessary to map Things into the UI. In the new bindings world, it seems that most examples would have me instantiate an NSObjectController in the nib to interface with the nib's owner (ThingViewController).

Isn't this "controller crud" exactly what bindings are supposed to diminish? Is there anything wrong with the following approach?

1. Design a view of model Thing in ThingView.nib.
2. Designate file's owner of ThingView to NSObjectController.
3. Bind all ThingView UI elements to file's owner.
4. Instantiate ThingViews in code by:
	a. Instantiating an NSObjectController (myThingController).
	b. Loading the ThingView nib with that as the owner.
	c. Programatically bind myThingController to Thing model.

I know there are retain count issues that have been discussed when attempting to bind to NSWindowController or NSDocument as file's owner. I assume those don't apply to NSObjectController. Am I wrong?

What's the best way to apply bindings to a "favors separate nib files" approach to view design?

Daniel

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: Tiger seeds download problems
  • Next by Date: Why don't I get "control reaches end of non-void function" warnings?
  • Previous by thread: Re: Tiger seeds download problems
  • Next by thread: Why don't I get "control reaches end of non-void function" warnings?
  • Index(es):
    • Date
    • Thread