[Templates] Template Tookit Vs HTML::Template

[Andy Wardley]

Perrin Harkins wrote:
> That definitely is what I've always meant by MVC.  

When I said "Most people don't seem to understand MVC..." I should have 
added "...present company excepted, of course"  :-)

> I could say something like "command classes + data objects + 
> templates", but it doesn't have the same ring or historical proof behind it.

Sure, I realise that most people use the term to mean something slightly 
different to what Smalltalkers or the Gang of Four would call MVC.  I guess
I even use it myself in that context.

What annoys me is when I hear that TT can't be used to build MVC systems 
because it allows objects in the code, subroutine callbacks, embedded
Perl code (which is disabled by default) and so on.  This is pure nonsense
written by people who clearly don't understand MVC, TT, or both.

I've seen at least one cleanly written and well abstracted system written
in Embperl (yep, pure embedded Perl) and some hideously crufty crap written
using HTML::Template.  But some people (present company excepted, of 
course :-) would have you believe that HTML::Template is the only 
template module worth using because it's the only one that supports MVC.

These people are not worth saving...  It's too late for them  :-)

(I should point out that World Domination is not my thing - I'm quite
happy that HTML::Template rocks at whatever it does, and I'm well aware 
that TT sucks at certain things - it's the misinformation and miseducation
that I'm trying to address)

> Of course some people use MVC to abstract different types of inputs as 
> well (web browser vs. cell phone vs. cron job), but that's not common.

As I was writing my tirade, I did wonder if you could build a pure MVC
system, treating each incoming URL like a controller and each side-effect
(including data impressions, page generation, etc.) as a view.  

But I haven't quite managed to get my head around that crazy idea yet...

> Is there a better way to describe this sort of thing without the baggage 
> of arguing about what a controller is, etc.?

I suppose that in the end, a name is just a name.  It's fine to call it
MVC, ABC or XYZ, or whatever best gets across the message.

But I think we should also preach caution against taking the word of MVC
too literally.  It's better to teach people how to build well abstracted
systems, than give then a set of strict rules to follow that may not be 
all that relevant.  Objects, callbacks, and embedded Perl do not, by 
themselves, break MVC or create a poor separation of concerns.  

Hmmm, there might be a TPC paper in this...

A