Re: Keep sibling view in Responder Chain
Re: Keep sibling view in Responder Chain
- Subject: Re: Keep sibling view in Responder Chain
- From: Quincey Morris <email@hidden>
- Date: Sat, 28 Dec 2013 21:23:42 -0800
On Dec 28, 2013, at 20:47 , Trygve Inda <email@hidden> wrote:
> That would require 10.7 and I am not sure if I am ready to stop supporting
> 10.6 yet.
What’s wrong with the even more straightforward approach of implementing each action method in an object that’s going to be in the responder chain at the correct time? You mentioned this in your original post, but didn’t really seem to take it seriously. It’s not more “correct” to implement actions in a view. AFAIK it’s just as correct to implement actions in controllers instead of views. The only real difference is that for views that are intended to be reusable in various kinds of windows (for example NSTextField or NSTextView), it’s a “packaging” convenience for the view to contain all its actions.
Assuming that the action really is something that the view needs to process (because it refers to state internal to the view), then I don’t see a problem in implementing the action in the view and implementing a same-named action method in the window controller, document or app delegate, and calling the view’s implementation.
If the action doesn’t need the view’s internal state (even if it does something to the view through its public interface), then I don’t see a problem in putting *the* action method in the window controller or document or app delegate. It can call non-action methods in the view as necessary.
Under these circumstance you would, of course, need to do the menu validation in the object that’s originally receiving the view, and you would set the target to First Responder in IB.
This is far easier than mucking about with the responder chain.
A couple of other points:
— It’s perhaps more logical to implement a menu action at a higher level than the view, if the action *only* originates from menus. My reasoning is that otherwise you’ve built knowledge of the menus into the view (the view contains actions “for” the menus, in a sense), which is somewhat of a MVC violation, or at least a smell. (Of course, many standard views and controls do it anyway.)
— For some actions which can be done either from a menu or from a control in a window, you may want the menu action to be slightly different, for user feedback reasons. For example, if you have a button in the window that performs some action, you may want the menu version to do a ‘performClick:’ on the button, instead of invoking the view’s action method directly, so that the user sees feedback that the menu is doing what the button would do.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden