On Jun 26, 2008, at 6:29 AM, I. Savant wrote:
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 // ... }
The core problem with what your describing is right there. If you have 1 button, in 1 app it works great. If you have 2 buttons it works in the same place it works ok. If you have 2 buttons in 2 different places or, even worse, 2 different apps it stinks. The only way to get the code to both places is cut and paste. Cut and Paste automatically moves this idea to the bottom. Concerns about MVCism are completely swamped by having copies of code everywhere.
Even if his scenario matches your description, is a big switch statement really a good solution? Your suggesting that he throw away the whole point of the IBAction methodology (sending events to the actual method that is going to process them) for what advantage? What's he's describing IS view behavior. It's a type of button. It's not the same type of button as Apple already implements, but it's most certainly a button.
You can argue that he should implement his button logic in IBAction for pragmatic reasons that he shouldn't go to the trouble of subclassing for a control he's only going to use once, but on pure MVC ground I don't think you can argue that this isn't part of the view.
-Kevin Elliott [EMAIL PROTECTED] DTS Engineer, CoreOS/HW _______________________________________________ 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]
