Is it acceptable to do a MVC where the View is an interface implemented by subclasses of objects in the Model and the Controller is just one
big proxy object that bares the brunt of the changing interface?
I guess the real question is, if you have objects, such as cart items, should a subclass of them serve as the widget
representing that item?
'Cuz, I mean, c'mon, you know... a View is just a specialized case of the Model, right?
Normally the logic (Model) side and the presentation (View) side of objects are in parallel inheritance heirarchies (right?) and
they both register through a proxy (the controller) that translates events from one to something the other can understand.
In this application, I have aggregations of
objects.
It's CGI, so events aren't directed to the
exact correct component -- instead, everything goes to the same place.
Where does that go?
It's in the controller now.
Yuck.
So the controller is really kind of the view
and the view is kind of really the controller.
Except that then the controller would have
HTML snippets stuck in it.
I think it's going to take a few more
iterations to get this right.
-scott
Inheritance sucks for this. The beauty of MVC is that one view might be able to represent any number of models. If you leave multiple inheritance out of the game (and you really should here), a view that is a subclass of a model can only represent a single model.
