Re: beyond MV and (one) C

FROM : mmalc crawford
DATE : Sun Jan 13 19:35:09 2008

On Jan 13, 2008, at 8:59 AM, Daniel Child wrote:
>> This is discussed in  <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/chapter_5_section_4.html

>>
> Chapter 5 section 4 is about the target action paradigm. If you mean 
> Chapter 4 (Cocoa Design Patterns)
>

??
When I click on the link, it takes me straight to "The Model-View-
Controller Design Pattern".

> I had read that (and just reread it), but I don't see obvious 
> answers to my question. Maybe a clue is buried in the discussion of 
> mediating and coordinating controllers.
>

The section on mediating and coordinating controllers deals entirely 
with your situation -- I'm not sure why you think there's just a clue 
buried in there?

> "In a well-designed Cocoa MVC application, coordinating controller 
> objects often "own" mediating controllers, which are archived in nib 
> files."
> While that gives me a vague sense that I should explore the canned 
> controller classes (and bindings), it says nothing about how many 
> controllers to use for the various model parts.
>


The controller is what's mediating between the model and the view 
("Controller Objects Tie the Model to the View").  The number of model 
parts is largely immaterial -- it's how you want to display them 
that's important.  For example, if you're displaying an array of 
objects in a table view, it doesn't matter how many objects there are 
in the table view, you still have one table view and (in the basic MVC 
case) one controller...
Additional controllers come into play if you want to devolve 
responsibility for managing a fairly self-contained subset of the UI 
to a separate controller.  NSWindowController is perhaps the "biggest 
granularity" example where rather than an NSDocument instance being 
responsible for multiple windows it can devolve responsibility to 
individual window controllers.  A window controller might then devolve 
responsibility for managing, say, a table view to an NSArray 
controller.  Or for a custom view you might implement your own 
NSViewController. It's all up to you to decide how you want to factor 
out the workload.

mmalc