> I think (or at least I hope) Kevin misspoke and meant View rather than
> Model, since that would make more sense if you're talking about subclassing
> NSButton.
You may be right about that ... but I answer what I see. ;-)
> I think "application-specific" is a little too strong. No one's proposing a
> button class that has any knowledge of *why* it has the behavior it has,
> only a slight variation on how it responds to a click.
Except that NSButton (if we ignore appearance for a moment) is
already perfectly capable of doing what the OP requires with no
modification whatsoever. The "animated latch" appearance that was
suggested previously is certainly neat-sounding but would admittedly
require more than the standard NSButton/Cell; if you just want a
custom static appearance, no subclassing is necessary - use a custom
image.
> I'm not sure this is any more application-specific than saying only one of a
> bank of radio
> buttons can be selected.
Well, "too strong" might be accurate - by "application-specific" I
mean specific to any given application, not necessarily that one
application. Still, the controller and (more-so) the model layers are
more application-specific. Views are intended not to be. That's my
(maybe-not-so-humble) interpretation of the MVC design pattern,
anyway. I welcome debate. :-)
> Sure, and in the case of one button and one action Kevin actually agrees
> with you.
I cede that point - I didn't mean to imply (or say?) otherwise, sorry.
> If you find yourself repeating those two lines in lots of places,
> then I think it's fair to at least consider factoring that logic out
> somewhere.
Sure - if you're using a button in this way in many apps or across
many controllers, there'd be an advantage (I suppose) of reducing it
to one line (to set the "disables when on" mode), but not much, I'd
argue. Again, this assumes no subclassing is needed for a special
custom appearance.
I'm envisioning a scenario where, even if there are a dozen such
buttons, they probably all connect to an action in the same controller
(or if they don't, it's easy to make them do so, to funnel all this
special behavior through one action that maybe calls others as
necessary). Consider:
- (IBAction)engageLatch:(id)sender
{
// Force on and disabled state
// ...
// Switch based on the sender and call any
// necessary additional actions, or flush the toilet, whatever
// ...
}
> I think a case could be made either way.
Sure. I just think one of them is 'wrong'. ;-)
> Personally, I wouldn't subclass NSButton for just one button or even, say,
> four buttons.
> It would just feel like going against the grain somehow; subclassing controls
> should
> be pretty rare.
This is why - I agree 100% here. Additionally, I *love* simplicity
and elegance. I think it is complicated and quite inelegant to make a
custom control in the scenario I mentioned. If Mr. Teeson says the
above is *not* the case, then I'd reconsider. Assuming all the above,
however (including no special needs for a custom appearance like
animation, etc.), then I must respectfully (if a bit irreverently)
assert that subclassing NSButton/Cell is silly (i.e., 'mountain out of
a molehill').
--
I.S.
_______________________________________________
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 [EMAIL PROTECTED]
