Re: insertObject:in<Key>AtIndex: not being called.
Re: insertObject:in<Key>AtIndex: not being called.
- Subject: Re: insertObject:in<Key>AtIndex: not being called.
- From: Paul Szego <email@hidden>
- Date: Tue, 5 Apr 2005 08:13:00 +1200
On 03/04/2005, at 9:55 PM, mmalcolm crawford wrote:
On Apr 3, 2005, at 1:51 AM, mmalcolm crawford wrote:
Which leads to me next question about bindings, which I've posted
elsewhere. If I bind a to-many property that's providing indexed
accessors, the default bind: behaviour provided in NSObject tries to
call setValue:forKey: instead of using mutableArrayValueForKeyPath:,
and so I get a "not KVC compliant" error message. Is this what
should happen?
No -- assuming you're using an array controller?
Hmm, I may have misinterpreted your question. Could you clarify
what's being bound where?
My fault, I wasn't too clear on that one. I've got two objects,
instances of "custom" classes, i.e. neither is an AppKit view or
controller. If both have KVC compliant access for a property, but
nothing else, what should I expect from doing a bind: between an object
of each class?
e.g.
MyFirstClasss* observed = ...
MyOtherClass* bound = ...
[bound bind:@"items" toObject:observed withKeyPath:@"stuff"
options:nil];
Assuming both 'items' and 'stuff' are KVC compliant. If I've not
bothered to write code to implement an "items" binding, something does
happen, but not necessarily anything useful. I appear to get some proxy
observer created (an NSObjectParameterBinder), which reacts to change
notifications to the observed property (via KVO?) and attempts to
propagate those changes to the bound property (using KVC?).
So there is some undocumented default behaviour, but it's not clear
what is going on. I believe the documentation is again misleading. It
takes a lot of reading to figure out that it's nothing more than a
convention - which is not obvious. All documentation on bindings that
I've read starts with KVC, then KVO. These are both cases where if you
follow some naming conventions then you do get behaviour for free. Then
you read on about bindings, and it's not clear that you don't - it's
all hand crafted. KVB is nothing more than a protocol. You don't get it
for free. In cases where bindings do already exist, it's because
someone's already hand crafted them.
In the case I initially posted about, the property happened to be a
to-many property that only provided indexed accessors. In that case the
proxy observer generated (NSObjectParameterBinder) failed, as it
couldn't translate between a change notification of kind Setting to
updates via indexed accessors. If I had been binding to an
NSArrayController I expect it does know how to handle such cases for
updating it's own property, hence your initial response?
Having not used Smalltalk in anger for about a decade, and only just
getting back into ObjC for about 6 months, my naive expectation was
that if I tried to do something that shouldn't work then it would be
obvious. In the case of doing a bind: to a binding that doesn't exist,
it didn't obviously fail. Something happened, which just added to the
confusion.
After all the considerable poking around to figure this out, it's
obvious there are numerous "private" classes under the covers that help
implement the bindings that have been written (e.g. the
NSObjectParameterBinder). It would be nice if some of these were opened
up, so that the rest of us writing our own bindings might get a kick
start. I understand this is no small task - making a class part of a
public API takes a lot more work, and has consequences. But it would
help the adoption of the technology considerably.
So I guess the summary is:
- I think the documentation needs a LOT of work to make this clear. IMO
it's very misleading.
- what is the intention of the default bind: implementation, if any?
- it would be nice if there was a little more support for writing your
own bindings from the framework classes.
Thanks, Paul.
_______________________________________________
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