Re: beyond MV and (one) C
Re: beyond MV and (one) C
- Subject: Re: beyond MV and (one) C
- From: mmalc crawford <email@hidden>
- Date: Sun, 13 Jan 2008 10:35:09 -0800
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
_______________________________________________
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