How much does NSObject's bind:toObject:withKeyPath:options: do?
How much does NSObject's bind:toObject:withKeyPath:options: do?
- Subject: How much does NSObject's bind:toObject:withKeyPath:options: do?
- From: Mailing list subscriptions <email@hidden>
- Date: Thu, 21 Sep 2006 12:35:53 +0200
In all the examples of using bind:toObject:withKeyPath:options: with
custom classes that that I've seen so far, the subclass overrides the
existing bind:toObject:withKeyPath:options: implementation.
I have a class of my own and I want to programmatically set up some
bindings using bind:toObject:withKeyPath:options:. My question is,
how much does the NSObject implementation of
bind:toObject:withKeyPath:options: actually do, if anything? Can I
just inherit it and expect things to work?
Background info:
- my class is a controller class; not a model or a view
- some aspects of the behaviour of the controller should change
according to user preferences
- I'd therefore like to bind a couple of instance variables in the
controller to the corresponding values in the NSUserDefaults,
mediated via NSUserDefaultsController
As such, I really only need my controller to:
- in bind:toObject:withKeyPath:options: call
addObserver:forKeyPath:options:context: to start observing
- in observeValueForKeyPath:ofObject:change:context: update the
corresponding instance variables
Basically I'd like to know whether any of this stuff comes "for free"
with NSObject, or whether I'll have to do it manually... I ask
because I haven't seen any examples which explicitly handle this kind
of relationship:
Model (NSUserDefaults) <-> Controller (NSUserDefaultsController) <->
Other controller (my custom controller class)
I've only seen this kind of example, and in many such cases no glue
code needs to be written at all:
Model (a class) <-> Controller (NSController subclass) <-> View
(NSView subclass)
Is the kind of interaction I'm proposing (Model <-> Controller <->
Controller) a valid use for Cocoa Bindings, or am I trying to use it
for something for which it was not intended?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden