On May 14, 2009, at 04:51, malte.phil...@mac.com wrote:
Now here is what has me utterly confused and my actual question:
In his tutorial Scott is setting up an NSObjectController (named
"ControllerAlias" there) and binds that to the "MyController"
instance with the explanation:
<quote>
This little green box is your "bridge" between the code in
MyController.m and the bindings system.
</quote>
The two NSArrayControllers afterwards are bound to that
'ControllerAlias' NSObjectController.
Aaron in his book has me creating an NSArrayController and bind that
directly to the instance with the array to be controlled.
Essentially skipping the NSObjectController entirely. When I just
thought it was my "bridge to the bindings system"?
Your confusion is justified -- because the statement about a
NSObjectController being a bridge to the bindings system is pretty
much false. Whatever Stevenson actually meant isn't clear, since he
doesn't explain why he sets things up the way he does.
You can use bindings without any NS...Controller objects. For example,
you can bind a NSButton directly to File's Owner (with some suitable
model key).
You use NS...Controller objects when they provide functionality you
need. The prime example is NSArrayController, which provides a lot of
useful functionality (sorting, filtering, selection maintenance) for a
NSTableView.
The problem with NSObjectController is that it provides almost no
functionality. It does respond to commitEditing: by sending
commitEditing: to all of the editors bound to it, and that can be a
useful convenience. Other than that, it doesn't do an awful lot.
Note that the picture is a little different if you check the "prepares
content" option on a NS...Controller. In that case, the NS.Controller
object is also responsible for creating its content object(s). For
example, IIRC Apple's NSPersistentDocument tutorial uses this
technique to create an initial Department object. In that case, the
NS...Controller has a non-trivial function, mostly as a convenience
for avoiding writing a line or two of code.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
