[Templates] Template Tookit Vs HTML::Template
Mon, 18 Nov 2002 11:57:36 +0000
Sea Bass wrote:
> I've heard people say that the ability to access objects directly breaks "MVC"
> separation. I'm not sure what MVC they are talking about, because in
> Smalltalk's MVC allowing "View" code to query "Model" objects is a necessary
> part of the pattern.
I have come to the conclusion that most people who talk about MVC in regard
to web application design don't properly understand what it is, how it
should be used, what it's good for and more importantly, what it's not
Traditional MVC is ideally suited to time invariant applications
(like your typical windowing application). Your application might have
3 dozen different buttons, sliders, entry fields, window controls, and
so on. Any of these "controls" can be pressed at any one particular time,
should signal the application "model" to do the Right Thing, and then
cause one or more display "views" to be updated to reflect the new state
of the model.
MVC is designed to solve the problem of *simultaneously* having multiple
control entry points, and multiple display outputs, and it acheives that
very elegantly. But web applications only ever have one entry point and
one output point - the request and the response. You *never* have multiple
simultaneous controls or views to worry about, so there's little point
applying traditional MVC to solve this non-existant problem. Your
application, be it a CGI script, mod_perl handler, or even an all-in-one
embedded Perl template, receives one and only one request for any one
invocation, and it must generate one and only one response. Flow of control
is linear and predicatable.
Desktop MVC applications are typically single-user and the in-memory model
persists for a session (e.g. while the application is running). In contrast,
web applications are multi-user, and in most cases, the per-user model is
regenerated on each request (i.e. by restoring a user's session data from a
database on each request). There are other differences: controllers are
inputs, not chunks of application code as they are portrayed in many web
application frameworks; presentation elements can safely contain
"programming" code, as long as it's presentation programming, not application
programming; the model is the application state, not the application
architecture, and so on.
What the MVC-for-the-web crowd are really trying to achieve is a clear
separation of concerns. Put your database code in one place, your
application code in another, your presentation code in a third place.
That way, you can chop and change different elements at will,
hopefully without affecting the other parts (depending on how well your
concerns are separated, of course). This is common sense and good practice.
MVC achieves this separation of concerns as a by-product of clearly
separating inputs (controls) and outputs (views).
So IMHO, it's separation of concerns they should worry about, not MVC.
The two are different things, albeit working in a similar manner. MVC
is (mostly) designed to solve problems that web applications don't have.
It is by no means the be-all and end-all of design patterns for web
programming. Far from it.
In fact, there are plenty of other design patterns that are equally, or
more relevant to web applications and to writing good, solid code that
clearly separates concerns. For example, the Chain of Responsibility
(to implement a pipeline processing model), Mediator/Facade (to abstract
internals behind clean interfaces to ease SOC), Strategy (to define
a general strategy for all web applications that can be specialised
for different requests), Abstract Factory and Factory Methods (to
allow different implementations to be switched in/out) and so on.
Alas, it seems that many web developers (and template module authors),
miss these because they've been told that MVC is all they ever need.
> 2) TT syntax is orthagonal to HTML/XML. I like having template code stand out
> from my HTML/XML code. After all, their purposes are very different.
Absolutely. Separation of concerns. Keep similar things similar, and
different things different.