Controllers and Cocoa

Rather than defining pure Ruby controller classes, the book should show how to leverage the Cocoa controller classes. For example, the WindowController class descends from Controller rather than NSWindowController; it should really be a subclass of Cocoa’s NSWindowController class, so it can take advantage of the built-in Cocoa functionality.

Similarly, presenting the log via a “tree-structured view” — which on Mac OS X is called an outline view — should be done using an NSTreeController.

Cocoa is not Rails, it’s a distinct framework with its own architecture. Developers, especially those just learning the framework, need to learn to follow the architecture provided by Cocoa to both get the best experience developing with it and take the best advantage of the framework’s features.

I’m going to introduce an NSWindowController in the chapter I’m writing right now, where it’ll be used for a preference pane. Since so much of what NSWindowController does is tied to assumptions about a document-centric architecture, I’m planning on putting off most discussion until I have a chapter where I migrate the log from an ephemeral stream of text to a save-able document.

I was planning on moving the log from a stream of text in a text box to an editable tree structured view. I’m starting to wonder if I’ll have the pages to do that, though.

My teaching style tends toward the bottom up, so I’m more likely to show how to use lower-level building blocks before higher-level ones that (often) replace them. I’m not dogmatic about that, though.