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: "Vitaly Ovchinnikov" <email@hidden>
- Date: Tue, 20 Jan 2009 12:02:22 +0300
Thanks to all,
I replaced array of dictionaries with array of custom objects, that
hold other objects that are used for binding.
And then I implemented lazy evaluation of data exactly when they are
necessary. In those "leaf"-objects.
Now calculations start exactly when I want to show the data :)
Actually I left -contentArray and will/didChangeValueForKey calls to
notify array controller about changes in array itself, but even when I
change array - objects that it holds stay the same, and no additional
calculations performed.
Btw, is it correct to implement -copyWithZone this way:
- (id) copyWithZone: (NSZone *) zone { return [self retain]; }
?
My first implementation performed a deep copy of my objects and every
column of the grid requested new lazy-computing object before drawing.
So each drawing caused new calculations. To prevent this I wrote a
code above and now it works fine. Will I have any problem with this? I
counted constructor and destructor calls for my objects, they are
equal.
On Tue, Jan 20, 2009 at 8:07 AM, Quincey Morris
<email@hidden> wrote:
> 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
>
_______________________________________________
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