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 (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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to