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 -- http://mail.python.org/mailman/listinfo/python-list
