Re: Responder Chain and NSViewController in non-doc applications
Re: Responder Chain and NSViewController in non-doc applications
- Subject: Re: Responder Chain and NSViewController in non-doc applications
- From: Jonathan Dann <email@hidden>
- Date: Mon, 30 Jun 2008 19:13:16 +0100
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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