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: Tue, 28 Feb 2012 18:47:32 +0100
Den 18:05 28. februar 2012 skrev Keary Suska
<email@hidden> følgende:
> On Feb 28, 2012, at 8:24 AM, Per Bull Holmen wrote:
> This all leads to a question, though, which is: what is the problem you are trying to solve? Is this a case of premature optimization? Why not just have the whole tree in memory?
>
> Overriding KVC methods is rarely a good way to go, especially if performance is a concern. If you want dynamism and scalability, you have a good case for using Core Data.
Thanks for your help. The problem I am trying to solve is, I want to
make a controller which lets me bind Cocoa controls to a plug-in
interface (audio units). This way, I can bind most of the controls
directly to audio unit parameters and properties, and set up fairly
complex UI logic for my audio unit the way I am used to in IB. Though
it would be nowhere as powerful as in an all-cocoa app. But, as the
people on the coreaudio-api list warned me, the interface to talk to
and set parameters/properties for an audio unit (through a straight C
api, and integer parameter-IDs instead of string keys etc...) does not
map easily to the Cocoa bindings way... :) In this case, an audio unit
instance (which is a plug-in) is the model, but it doesn't talk Cocoa.
Binding to the VALUES did still turn out pretty well now. But the
Audio Unit plugin API also has a standardized way for Audio Units to
give the hosts and GUI some static information about each parameter
such as min/max value, readonly or writable etc. To be able to bind to
this information too, it would be much easier for me to let the
controller just fetch this information on the fly, and notify
observers the few times it changes. Building a tree in memory would
require more bookkeeping, and would be harder because the controller
can not know in advance what string keys (which maps to parameters
IDs) it will be queried for, the controller is supposed to not have
any knowledge in advance of the possible model keys. But yeah, I'll
solve it either way. So now I know, there is no shortcut, I must make
every property on the key path KVC and KVO compliant. I'm not
complaining... :)
Thanks for your help.
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