This thread is a bit long in the tooth but I thought I would conclude it. My final solution to this was not to try and split a separate NSResponder class off from my NSViewController. I could have been gone down this route but the sheer amount of donkey work put me off. The app was designed to work with NSViewController instances between the NSWindow and the NSWindowController in the chain - period. The 10.10 API changes simply invalidated my design. You could argue that the NSViewController should not have been inserted into the chain as I had done but there was nothing that I know of that would have mandated against this design.
Anyhow, my fix was to give my controllers an additional NSViewController proxy property. The proxy does not load the controller’s nib, it merely references the parent controller’s view and participates in the auto responder chain building. The parent controller can then be inserted higher up in the responder chain as before. https://github.com/mugginsoft/XSViewController/commit/29b406a4e1882edea2203eaff3c44f1c6a2f4cbd > On 4 Oct 2015, at 11:02, Jonathan Mitchell <[email protected]> wrote: > > >> On 3 Oct 2015, at 18:43, Quincey Morris >> <[email protected]> wrote: >> >> >> I suggest you consider breaking your view controllers apart into two >> objects. One, a “view responder” would be a NSResponder subclass that you >> insert into the responder chain just below the window controller. The other, >> an actual NSViewController subclass, would be inserted into the responder >> chain wherever the frameworks want, or possibly not at all pre-10.10. > That’s a good idea! > >> >> Ideally, all of the business logic would be moved from its current home in >> the view controller to the view responder, including the action messages. >> All that’d be left in the view controller would be the outlets (if any), and >> the viewDidLoad logic necessary to prepare the view itself (and also to >> create the view responder, and insert it in the responder chain). >> Alternatively, you could keep all the local-to-view logic in the view >> controller, and put only the trans-view logic in the view responder, but >> this may get a bit messy if both share the same custom data structures. > > The business logic is all in a separate framework. > The view controllers simply hookup the UI bindings by calling into the BL. > So I might go along the lines of of an additional lightweight NSResponder > that acts an action receiver that routes actions back to proxies in the view > controller. > > Or, it might be simpler to just accept the 10.10 design changes and refactor > accordingly. > In the long term this might be best in terms of reducing overall complexity. > > Thanks a bunch for you input. It helped a lot. > > J _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
