Re: Responder Chain and NSViewController in non-doc applications

FROM : Jonathan Dann
DATE : Mon Jun 30 20:13:16 2008

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

>
> 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?
>

In the NS world yes, but it makes sense often  to have the controller 
respond to actions.

> 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