Re: Bindings and KVO of View objects
Re: Bindings and KVO of View objects
- Subject: Re: Bindings and KVO of View objects
- From: Quincey Morris <email@hidden>
- Date: Wed, 20 May 2009 03:27:12 -0700
On May 19, 2009, at 17:22, Stuart Malin wrote:
I don't see why it is a design flaw to want to bind to the
selectedIndex of a segmented control so that when the user changes
the selected segment, my code to take action. Binding to the control
is conceptually quite similar. The two approaches to me seem to be
matters of implementation specifics.
I'm not quite sure what you're saying here. You can't bind *to* "the
selectedIndex of a segmented control" because (again) there's no such
property -- "selectedIndex" is a binding name, not a property name.
You can bind to the selectedSegment of a segmented control, and that
will indeed produce a notification when the state of the control
changes.
But that's just about terminology. My point was this:
Binding to the state of a control only tells you the state of the
control. If you reason, "Oh, but the control is bound to a data model
value, so the state of the control always reflects the data model
value" then you've introduced a lot of information about the interface
implementation with no actual benefit -- if your information is
correct, then you may as well have bound directly to the data model.
Really (or so runs my argument) the only case where there's any point
in binding to a user interface element is when you definitely want to
know the UI element's state, and not the data model value, in a
situation where the two could be different. (Again, if they can't be
different, then binding to the data model value is the better choice.)
Also, on May 19, 2009, at 14:18, Stuart Malin wrote:
My specific concern is with NSSegmentedControl, which has a bindable
property "selectedIndex". I am trying to add an observer for this
property (using -addObserver: on an instance).
So you've written code which "unnecessarily" knows about the
construction of the user interface, so the UI is no longer neatly
partitioned off in your NIB file. Changing the UI means you'll have to
change code. But if you observe the data model instead, the UI is not
a factor or a maintenance headache.
_______________________________________________
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