On Thu, May 30, 2002 at 05:42:23PM -0400, Jesse Erlbaum wrote: > It has been my experience that applying a design pattern such as MVC is not > a panacea. [...] > My point: My > code isn't good because I apply some "pattern" to it. It may be good, and > it may resemble a pattern -- but those two things are largely coincidental.
Absolutely! > The View, in a web application, is really the HTML output. Generally, this > will be your templating system. Optimally, the View avoids *ALL* > application logic. At my company we use HTML::Template because it strongly > enforces the separation of View from Controller -- e.g., HTML from code. (I > realize that many of you prefer other HTML templating systems, but I still > contend that HTML::Template is the most effective system for truly > separating HTML from code. And it's damn fast, too.) Enforcing a clear separation of View from Controller is not the same thing as not calling code from templates. It is perhaps the most misunderstood point about MVC and templates. There's nothing wrong with calling a subroutine or object method from a template as long as: * the code perform a presentation function (not an application one) * the code doesn't have any side-effects on the model or other controllers You can also call code to perform lazy data-loading as Perrin has already mentioned, but that does require a little more thought on the part of your back-end designers to ensure that things continue to behave as planned. Or you can break all the rules if you know what you're doing. I break the rules all the time when I'm knocking together a few quick and dirty web pages, generating an SQL report, or a Postscript page showing a graphical distribution of the first thousand prime numbers. MVC is good for big web sites, but overkill for quick hacks. A
