[Templates] Template Tookit Vs HTML::Template

[Andy Wardley]

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.

Indeed.

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
good for.

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.


A