Re: Question about KVC-compliance and bindings
Re: Question about KVC-compliance and bindings
- Subject: Re: Question about KVC-compliance and bindings
- From: Per Bull Holmen <email@hidden>
- Date: Wed, 29 Feb 2012 00:53:02 +0100
Den 23:41 28. februar 2012 skrev Keary Suska
<email@hidden> følgende:
> I would say that there really isn't anything wrong with the controller knowing ahead of time what keys in the model will be needed by the UI. In fact, it needs to, and in fact does when you establish a binding. It is simply abstract enough that it is easy to forget ;-)
>
Yes, it does know it when you establish a binding, I agree. That's
what I am currently doing, in the controller's addObserver method, it
registers the keys, and if there is a corresponding integer parameter
ID for the plug-in, puts it in an NSMapTable. Is this the right place
for the controller to determine that a binding is established? Is
there a more appropriate place?
Anyway, I can not see anywhere in the docs that they guarantee that
the view that does the binding does not call valueForKey: on the bound
object before it registers the object as an observer. Therefore I
ended up, in my valueForKey: override (more on that later), to FIRST
check if the key is in the map table, THEN if the key is not in the
map table, check if it still does correspond to a parameter in the
plug-in. That is almost the same thing as my addObserver method does.
That's not elegant, but I think it should be guaranteed that
valueForKey: behaves the same way regardless of whether a property is
being observed or not. If valueForKey: does not find a corresponding
parameter ID, it calls super. Regarding overriding valueForKey: (not
valueForKeyPath:) I don't see what's wrong that, since 99% of the time
valueForKey: is called, it will be with a key that correspond's to a
parameter ID, and not one that corresponds to an accessor, ivar or
obj-c property. Either way it will call super if it doesn't find a
corresponding parameter ID.
What I meant when I wrote that my controller should not know
beforehand what keys will be needed, was that the possible keys should
not be part of the implementation, ie. hardcoded. Also, the user
supplied delegate method that translates between string keys and
integer parameter-IDs, should be as easy to implement, yet as flexible
as possible. Therefore I just let it take a string value as arg and
translate to an integer ID, rather than requiring that it returns,
say, a complete dictionary with all the keys and associated info at
once.
Per
_______________________________________________
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