On 30 Jun 2008, at 17:52, Jerry Isdale wrote:
I'm trying to understand a bit more about the Responder chain, especially how it relates to regular (non-document) applications using NSView and NSViewController added into the View Hierarchy. Katidev.com has a nice series of articles on the related issue for Document based applications. (It starts at http://katidev.com/blog/2008/04/09/nsviewcontroller-the-new-c-in-mvc-pt-1-of-3/)However, it doesnt give me enough background to understand why I need a XSViewController (extension of NSViewController), and how the Controller hierarchy fits in with the View Hierarchy.
Sorry if we didn't explain it quite well enough in the articles, the main idea behind why we need the controllers can be found from our initial conversations on this list (sorry about my spelling on the first post, I was still getting used to the iPhone!)
http://www.cocoabuilder.com/archive/message/cocoa/2008/3/19/201743 The main points we wanted to address were:1) How do you fit an NSViewController into the MVC architechure when all the docs only refer to the roles of the NSDocument and NSWindowControllers. 2) How do you deal with the issues of programmatic bindings when windows are deallocated while observers are registered. 3) As NSViewController is a subclass of NSResponder, where should is go in the responder chain and how can we automate the addition of a view controller to the chain so we don't have to explicitly add it and remove it from then chain when we need to create and get rid of controllers and their associated views.
When does an application following the Responder Chain look at the ViewController?
Events are sent up the responder chain, so the firstResponder will likely be the view you click on (an NSButton for example) or actions sent from the key window. Just as in the docs they travel to the window controller, but then the view controller hierarchy is the then patched in so each view controller gets a chance to respond to the sent action. If by the end of the view hierarchy the action is still not responded to, the action gets passed to what whatever is after the window controller is Apple's documentation (I forget what it is, the NSApplication delegate, maybe?)
Event Messages (aka events) dont get passed to the NSViewController in the normal (NS) world.
Correct. Which is odd until you realise that NSViewController by itself cannot be put into the chain by default until an architecture for the class is decided upon. We chose a tree to reflect the view hierarchy, some choose an array controllers.
The XSController extension (katidev.com) puts these back in, such that it when the event gets to the XSWindowController it would get passed down the XS-responder chain (see the article).
Yep, solves a lot of problems, but note that it is not the only place that putting the controllers into the chain makes sense. Some prefer to make each controller the nextResponder of its view, and then interject the next responder of the view controller to the original next responder of the view. The next version of the class may have this option, but its a simple case to start observing changes to the view's nextResponder during the +loadView method and hijacking it when it changes.
Action Messages (actions) follow a slightly different path. Actions start by an Event responder (eg a ButtonCell) firing off a sendAction:to:from. If there is a designated Target (to:) defined by the responder, that object gets the action. Otherwise the sendAction:to:from goes to the First Responder, up the view hierarchy, to the NSWindow, to the WindowDelegate, to the NSApp then the AppDelegate
Yep
In the NS world yes, but it makes sense often to have the controller respond to actions.Again, the NSViewController doesnt appear in the responder chain, unless it was designated by the initial Event Responder. If it was designated, but doesnt respond, what happens? An Error or does it go back to the responder chain?
The NSViewController is a Responder, but the associated view does not patch it into the responder chain for either event or action responding.
Yes
But if my design explicitly specifies the target (connecting IBActions in InterfaceBuilder), I dont have to worry about the Responder chain for actions. Correct?
Yes, but with the controllers in the chain you have some flexibility. Thanks for reading the articles, Jonathan Dann www.espresso-served-here.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
