Cocoa mail archive
Re: Adding a new type of NSButton
FROM : Andy Lee
DATE : Wed Jun 25 23:10:52 2008
On Jun 25, 2008, at 4:26 PM, I. Savant wrote:
>> Other peoples comments about this being a "Controller" problem and
>> not
>> something that belongs in the Model are somewhat true, but if this
>> is really
>> a button type your going to use in several places then subclassing is
>> perfectly appropriate. Also, if it's important to you that the
>> user not get
>> any click behavior (that is, once the button has been "set" then
>> clicking on
>> it again has no visible effect on the control), then I don't think
>> you'll be
>> able to get what you want without subclassing.
>
> Incorrect. For several reasons.
>
> First, my comments had nothing to do with the model layer (this
> logic most definitely doesn't belong in the model layer).
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.
> In this case, you're suggesting that application-specific
> logic be added to an existing view that can already do what's needed
> (be pressed and disabled), rather than to the controller layer (which
> can tell it "in this case, once pressed, stay pressed - ie, set to on
> and disabled).
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. I'm not sure this is any more application-specific than saying
only one of a bank of radio buttons can be selected.
> Presumably, when the button is first pressed, it's
> firing an action ... all you need is two extra lines of code in that
> action to solve this problem (appearance notwithstanding).
Sure, and in the case of one button and one action Kevin actually
agrees with you. 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. I think a case could be made either way.
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.
--Andy
DATE : Wed Jun 25 23:10:52 2008
On Jun 25, 2008, at 4:26 PM, I. Savant wrote:
>> Other peoples comments about this being a "Controller" problem and
>> not
>> something that belongs in the Model are somewhat true, but if this
>> is really
>> a button type your going to use in several places then subclassing is
>> perfectly appropriate. Also, if it's important to you that the
>> user not get
>> any click behavior (that is, once the button has been "set" then
>> clicking on
>> it again has no visible effect on the control), then I don't think
>> you'll be
>> able to get what you want without subclassing.
>
> Incorrect. For several reasons.
>
> First, my comments had nothing to do with the model layer (this
> logic most definitely doesn't belong in the model layer).
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.
> In this case, you're suggesting that application-specific
> logic be added to an existing view that can already do what's needed
> (be pressed and disabled), rather than to the controller layer (which
> can tell it "in this case, once pressed, stay pressed - ie, set to on
> and disabled).
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. I'm not sure this is any more application-specific than saying
only one of a bank of radio buttons can be selected.
> Presumably, when the button is first pressed, it's
> firing an action ... all you need is two extra lines of code in that
> action to solve this problem (appearance notwithstanding).
Sure, and in the case of one button and one action Kevin actually
agrees with you. 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. I think a case could be made either way.
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.
--Andy
