Re: Binding of invisible controls: is lazy data loading possible?
Re: Binding of invisible controls: is lazy data loading possible?
- Subject: Re: Binding of invisible controls: is lazy data loading possible?
- From: Quincey Morris <email@hidden>
- Date: Mon, 19 Jan 2009 21:07:57 -0800
On Jan 19, 2009, at 17:33, mmalc Crawford wrote:
On Jan 19, 2009, at 5:25 PM, Quincey Morris wrote:
If anyone can find a place in any documentation or header files
that *says* the indexed to-many accessors (such as
insertObject:in<Key>AtIndex: and removeObjectFrom<Key>AtIndex:) are
KVO-compliant when used directly, you'd be doing a public service
by posting a link.
<http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueObserving/Concepts/KVOCompliance.html#//apple_ref/doc/uid/20002178
>
In order to be considered KVO-compliant for a specific property, a
class must ensure the following;
* The class must be key-value coding compliant for the property as
specified in “Ensuring KVC Compliance”.
->
<http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/Compliant.html#//apple_ref/doc/uid/20002172
>
Well, yes, but that's not the answer to my question. It says:
If the to-many related objects are mutable, and the -<key> method
does not return an NSMutableArray, you must also implement -
insertObject:in<Key>AtIndex: and -removeObjectFrom<Key>AtIndex:.
This says what a class needs to do to *be* KVO-compliant, not whether
calling these methods is the actual means of triggering the
notification -- it doesn't say what you need to call to *change* the
property KVO-compliantly.
I'm not just splitting hairs here, though I am parsing the terminology
very finely. If you go to the place where these accessors are actually
described:
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/AccessorConventions.html#/
/apple_ref/doc/uid/20002174-178830-BAJEDEFB
the only thing it says about how to get mutable access is:
The key-value coding methods mutableArrayValueForKey: and
mutableArrayValueForKeyPath: provide mutable access to a to-many
relationship, regardless of the class used to model the relationship.
In order to support these methods, your class must implement two
additional methods for each of these keys: -
insertObject:in<Key>AtIndex: and -removeObjectFrom<Key>AtIndex:.
[...] The example in Listing 6 shows the methods required to support
mutableArrayValueForKey: for the to-many transactions property.
From this, you could get the idea that the class must *have* the
accessors to "support" or "implement" KVO-compliance, but that you
must *use* the mutableArrayValue proxy to make the change. It's not
inconsistent with the documentation that the implementation of the
mutableArrayValue proxy class might be in effect like this:
[object willChange...];
[object insertObject: ... in<Key>AtIndex:...];
[object didChange...];
There's plenty of documentation that says that the insert/remove
methods are the implementation of the to-many access, but none that
they are suitable for the class's public interface.
IAC, the original quote is weird in other ways:
If the to-many related objects are mutable, and the -<key> method
does not return an NSMutableArray, you must also implement -
insertObject:in<Key>AtIndex: and -removeObjectFrom<Key>AtIndex:.
The mutability of the related objects is irrelevant: it's the
mutability of the relationship property itself that is at stake.
It also suggests that if the -<key> method *does* return a
NSMutableArray, you don't have to implement insert/remove methods but
the property is still KVO-compliant for changes. (I believe I have
code that actually relies on this, and that it does work, but I would
have to go searching for it to be sure.) This is not said anywhere
else (not in the mutableArrayValueForKey documentation, nor in
NSKeyValueCoding.h), and actually contradicts part of what Ken
Thomases said earlier in the thread. So that's yet another puzzle.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden