Model View Controller
I’ve been writing model-view-controller applications since Smalltalk-80 and the Tektronix 4404. I’m a big believer in the Gang of Four. I refactor for lunch.
But I’m getting very confused in my dotage. What are controllers for, anyway? Apple wants them to be mediators between model and view, and that makes sense for generic view parts like buttons where you don’t want to widget to know anything about the model.
But what are we supposed to do with, say, TinderboxMapItemView? The whole point of Tinderbox visualization is to pack a lot of visual information about difference facets of complex note objects into a small are of screen real estate. Some things that we need to unpack for displaying one note, for example, include:
- DisplayName
- Name
- Subtitle
- Text
- Child Count
- Text length
- Color
- Accent color
- Pattern (which might be a graph of any two attributes!)
- Fill
- Shadow (color, distance, blur)
- Font (and font size) for Title and Text
- Opacity
- Bold
- Strike through
- Checked
So, do we want to send the view a huge bundle of assorted properties? We already have a bundle of properties: it’s the object! And reuse is an open question here, too: are we more likely to want to reuse the model or the view?
So I’ve always let the view know about class Node and class Hypertext. In PowerPlant, LViews did double duty, combining the roles of View and Controller, and that was not always a good thing. Cocoa wants to use separate controllers, and that sounds good.
I don’t understand the Cocoa implementation. In particular, behavior is supposed to be in the Controller, but the Controller doesn’t receive actions and events. Instead, the View gets actions and events. Sure, we could forward them all to the controller, which gives you a partitioning, and that makes sense for generic views. But, if we’re letting the view know a little about class Node anyway, what do we gain by forwarding all the actions and events to another class?
Someone out there: set me right.