TK + MVC

[Gregory Ewing]

Alexander Kapps wrote:

> Sure, in that simple example the Controller is just there to show a 
> complete MVC pattern with all three parts. There are often examples 
> where the View is actually both, the View and the Controller.

I think what I'm really trying to say is that this
example is *poor* at illustrating the supposed MVC
pattern, because it gives no clue as to why one
might want to use a Controller.

> That's why I said that I'm not sure if I really understand the MVC 
> pattern. There are so many different versions, sometimes strict and 
> sometimes less strict, and I think what's the real problem with my 
> example is, whether it is really correct to not connect the Model and 
> the View directly, but to let the Controller "mediate" between both.

I don't blame you for being confused. Different people
seem to have different ideas about what the "C" in "MVC"
means.

As far as I can tell, in the original Smalltalk concept
of MVC, the View handled output and the Controller handled
input. In Apple's Cocoa tutorials, the Controller seems to
be something that sits between the View and the Model with
a somewhat ill-defined role. Then there are web frameworks
that call themselves "MVC" with their own strange twists
on what the terms mean.

One possible role for a Controller-like object would be
where the View is not a single widget, but some collection
of widgets that cooperate to provide a user interface.
In that case, the Controller could be something that
creates and assembles the relevant widgets, and provides
whatever glue code is needed to make them work together.
I suspect that this is what Apple mean by a Controller
in Cocoa.

I've certainly created this kind of structure, but I tend
not to use a separate object for it. Instead I create a
subclass of Window (Toplevel in Tk terms), or some other
container widget, to serve as both the coordinating object
and a container for all the parts. I don't think of it
as a Controller, but simply as a compound View that
happens to be made up of several objects.

So I don't think there's any single "correct" way to put
a "C" into "MVC", or even necessarily a need to put one
in at all. To my mind, the important things about the
concept of model-view separation are:

* The Model holds the data and provides a common
   interface for Views to access and change it.

* Multiple Views, and different kinds of View, can
   be attached to a Model through its common interface.

* There is some mechanism for a Model to broadcast
   an "I've changed" message to all its attached Views.

Whether the Views attach to the Model directly or through
some intermediate object is not really important. And
when there is an intermediate object, whether you call it
a Controller or regard it as simply another kind of View
is just a matter of perspective.

-- 
Greg