On May 20, 2009, at 1:04 AM, Quincey Morris wrote:
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.
NSSegmentedControl exposes a selectedIndex "binding"; there's no such
property. Further, there's no binding for selectedSegment, which is a
property. Curiously asymmetric.
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.)
Good points, well-taken.
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....
Anyway, all that said, thank you Quincy for your considered thoughts.
_______________________________________________
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
