Re: beyond MV and (one) C

FROM : mmalc crawford
DATE : Sun Jan 13 20:24:15 2008

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