Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)


My email address is Spam me harder! *moan*

Journal of scrottie (4167)

Friday July 15, 2005
05:42 PM

Model-View-Controller pattern questions

[ #25732 ]
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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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.