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 11:24:15 -0800
On Jan 13, 2008, at 10:35 AM, mmalc crawford wrote:
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...
"it doesn't matter how many objects there are in the table view" ->
"it doesn't matter how many objects there are in the array"
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. [...] It's all up to you to decide how you
want to factor out the workload.
Since the mention of the various NSControllers (in the Design Patterns
article) seems to be confusing, perhaps it might be worth thinking
about how you might factor out similar controllers yourself.
Suppose you have a corpus containing a number of documents, and you
want a table view that presents to the user the title of each document
so they can select one. You'd have a controller managing the corpus,
and acting as the table view's data source. Suppose then each
document is divided into sections, and you want to display in another
table view the titles of each section of the currently-selected
document. Again the original controller can manage this, and serve as
the data source for this new table view.
The controller can readily enough provide data for each table view
because the table data source methods include a reference to the table
view:
- (NSInteger)numberOfRowsInTableView:(NSTableView *)aTableView
The problem, though, is that the code for managing the table view
starts to become messy:
- (NSInteger)numberOfRowsInTableView:(NSTableView *)aTableView
{
if (aTableView == documentsTableView)
{
return [documentsArray count];
}
if (aTableView == sectionsTableView)
{
return [sectionsArray count];
}
// ...
}
So rather than putting all the code into one controller, you could
implement separate controllers -- DoucumentsTableController and
SectionsTableController -- to manage just the table views. You tell
each one which array it's managing, and if the array is mutable you
provide suitable methods to allow content changes to be communicated.
They'd implement the relevant table data source methods, but since
each is only responsible for a single table view you end up with
simpler code. When you look at the code for the two, you notice that
it's very similar -- and if you're able to leverage KVC to get and set
the document and section attributes, it may well be identical. So you
can refactor them into a single generic table controller that you can
also reuse elsewhere. And if you abstract this sufficiently, and
leverage other technologies (KVO, KVB) as well, you end up with
NSArrayController.
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