Re: Bindings and KVO of View objects
Re: Bindings and KVO of View objects
- Subject: Re: Bindings and KVO of View objects
- From: Ken Thomases <email@hidden>
- Date: Wed, 20 May 2009 11:37:32 -0500
On May 20, 2009, at 11:24 AM, Stuart Malin wrote:
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.
Also a good point, a key one in fact, for this is a driving reason
for MVC.
In the specific case which I am working with, the UI element does
not correspond to a model value of the application's data. The
control is used only to change the presentation of the model data.
Hence, a change to the UI would necessitate, well, corresponding
changes to the UI. In my implementation, only the UI controller (for
this portion of the UI) is affected by the state change of the
segmented control. I guess one could make an argument for the case
that this presentation state is a model attribute of the UI.
My solution turned out to be best handled by setting the selector
and target for the action of the control. On invocation of the
specified method, the controller adjusts the UI accordingly. Works
very cleanly, as the NSSegmentedControl takes care of changing its
visual state. Presently, there is no other way for this state to
change, but if I introduce one (say a menu option), then my
controller could always directly update the state of the segmented
control. Which would suggest having a UI model property of that
state and binding the control to it....
While target-action is perfectly fine for what you're trying to do, I
would point out that controller's can have properties, too. Binding
UI to a property of your controller is another good way to handle this
situation. It leaves the responsibility in the same place -- the
controller -- but does what bindings usually do: removes boilerplate
glue code.
Cheers,
Ken
_______________________________________________
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