Re: NSObjectController HELP
Re: NSObjectController HELP
- Subject: Re: NSObjectController HELP
- From: Allan Odgaard <email@hidden>
- Date: Sun, 6 Jun 2004 11:52:28 +0200
Vince Ackerman wrote:
[...] If I have to write special accessor methods then I might as well
go back and put my glue code using IBOutlet's and notifications back
in my project......
The accessor methods are not 'special'. And as of such, you can use
setValue:forKey: to change a value instead of writing your own
accessor, this will trigger the proper notifications.
mmalcolm crawford wrote:
I should like to mention that this stumped me as well, the first time
I worked with bindings. All documentation I'd read up till that
point (and indeed, even now) suggested everything was "magic" and
"automatic". [...]
I believe the documentation makes it clear that the technologies
underlying bindings are not magic [...]
In defense of Wade, the first 'Currency Converter with Bindings'
example did change the instance variable directly and did not send the
required setKeys:triggerChangeNotificationsForDependentKey: message,
implying a very strong presence of "magic" :) I am also positive that
the documentation explicitly did state that automatic change
notifications would be sent when changing the instance variables
directly.
Of cause most things have since been cleared up, although I personally
find it a tad confusing that the NSKeyValueBindingCreation document
* speaks of binding properties as "key value coding compliant" (and
state that they are accessed through KVC compliant methods)
* does not define the 'relationship' established by bind:...
* speaks of the protocol as implemented by NSObject but then goes on
to speak only of what view subclasses can do with it, although at least
controller subclasses would do the same (and the model<->controller
relationship seems to be unmentioned)
Also the Bindings Reference leaves a bit to be desired, e.g. it says
that "contentArray" of the NSArrayController should be "An NSArray
...". I think it should be explicitly stated, that the array
controller will in fact use mutableArrayValueForKeyPath: in order to
obtain the array, since that allows for much more flexibility in the
model. This point applies of cause to all bindings where the latter is
the case.
There are some things in the document which either I do not understand,
or which are wrong. Like stating that 'content' for NSTableView should
be bound to an NSArrayController instance. I assume the intent is an
array controlled by an array controller, but does the table view really
care? i.e. would not something that replies to arrayValueForKeyPath:
suffice (which again allow for more flexibility, but unlike the
previous example, unused by most)?
It might also help a lot with a section about implementing binding
support in own classes, like the rule about having the receiver of
bind:... add itself as observer and send KVC messages to the
'obserableController' (which, despite the diagrams, I have still not
seen described in text), the necessity of both a content and a
contentValues binding for editable to-many bindings (as previously
discussed on this list) etc.
And documented behavior on binding to KVC properties, contrary to
exposed binding properties and elaboration on the differences between
the two (stating that the former is unsupported would also work).
And while I am making wishes, some established policy on retaining
objects in context with bindings. As previously stated on this list,
some bindings can result in retain cycles (and thus leaks), but for me
this is only detectable by experiments, not by analysis :(
And also wether or not array operators can actually be observed (which,
also as previously stated on this list, only seems to be the case when
used on an array controller proxy).
But other than that, everything is fine! :)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.