Re: [Q] More clear documentation for the Cocoa Binding?
Re: [Q] More clear documentation for the Cocoa Binding?
- Subject: Re: [Q] More clear documentation for the Cocoa Binding?
- From: Keary Suska <email@hidden>
- Date: Mon, 15 Jan 2007 09:54:12 -0700
- Thread-topic: [Q] More clear documentation for the Cocoa Binding?
on 1/14/07 11:33 PM, email@hidden purportedly said:
Although it may not be obvious at first, NSObjectController and its
subclasses are not essential to the bindings technology. That is, you can
use bindings thoroughly without ever using these classes. They are two
different things--NSObjectController et al are really convenience classes
provided by Apple to facilitate the use of bindings.
> For the case 1, you provide the content of the NSObjectController by connect
> the instantiated model object to the NSObjectController via the "content"
> outlet of the NSObjectController. OK. It looks reasonable. However, when you
> open the NSObjectController's Binding property, you can see that the "content
> object" under "Controller Content" is not bounded to anything. What is this
> "content object" property? Anyway using the content outlet, the model is
> connected to the controller.
Of course--they are two different ways of setting the content parameter, to
address different ways that a controller may get its content. Setting the
content outlet does not set a content binding. Typically, you would use the
content outlet when your model object (or an object that acts like a model
object to the controller) is instantiated in your nib and therefore can be
connected using IB's outlet-setting feature. You typically use the content
binding when a different *controller* object (used in the broader
sense--i.e. not necessarily an NSObjectController) will provide content, via
key-value coding.
> For the case 2, a document (http://developer.apple.com/documentation/
> Cocoa/Conceptual/CocoaBindings/index.html#//apple_ref/doc/uid/ 10000167i )
> says that the model, which is an array of objects, not an object, is a
> content. ( Can't it be an object? ) Anyway, although you can see the "content"
> outlet there, but you should mark the array of the objects as the
> NSArrayController's content using its "content object" under "Controller
> Content" properties.
I am not sure what you are referencing here, but the docs say, under
"Setting the Content of a Controller," "The contentArray binding is bound to
an NSArray or an object that implements the appropriate array indexed
accessor methods." So an NSArrayController's content may be any type of
object, as long as the object uses indexed accessor methods. The idea is
that the controller expects its content to be an indexed collection of some
kind, but not necessarily an NSArray. As far as binding vs outlet, it is
exactly the same as NSObjectController, with the difference that each
controller expects a different kind of content object.
> Why are the both case so different and inconsistent?
They are different because they are addressing different controller issues.
One for dealing with a single set of object data, the second for dealing
with a series of object data. Consider that the default content class for an
NSObjectController is an NSMutableDictionary, and the default class for an
NSArrayController is an NSMutableArray. And, they are not inconsistent,
except insofar as they are dealing with different types of content. They are
not intended to be used interchangeably.
> Why doesn't it hide the other property which is not used?
Why should it? IB doesn't hide any properties that are unused or for which a
conflicting property is otherwise set. Otherwise, how would you change
properties? And this is an IB issue, and has nothing really to do with
bindings or controllers.
> The document doesn't explain them cleary. As far as I know, it
> doesn't explain it at all.
I would say that the docs are fairly thorough regarding bindings, although
you need a fairly thorough understanding of Key-Value Coding and Key-Value
Observing to better understand bindings. And these technologies are not
documented in the bindings docs, because they are aren't binding
technologies per se, but are used by bindings to do their "magic."
Notwithstanding that they are thoroughly documented elsewhere. The docs are
pretty clear about these prerequisites.
I can see that the docs aren't entirely clear about the role of
NSObjectControllers and bindings, and I can see how someone could think they
are dependent on each other. Perhaps that point could use clarification.
I would agree, on a different point, that the NSObjectController classes are
insufficiently documented for more "advanced" uses of the objects. I have
had a number of hair-pulling session trying to figure out what they are
doing behind the scenes. This could certainly be documented better (IMHO).
Best,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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