Den 23:41 28. februar 2012 skrev Keary Suska <cocoa-...@esoteritech.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
