Yes, it does, and the authors specifically state that having the template do all the heavy lifting violates standard practice for large applications. However, they do state that, for smaller sites, this can be beneficial.

In addition, having your templates talk to a database doesn't violate MVC, in and of itself. Let's take a real-world example that I have worked on - a site that is available in 12 languages. Obviously, what language you present in is a V-layer issue. So, when you want to specify the column names for your report, you indicate in your code (either in the template or in the script) that you want the names for column 1 .. 5 in language $lang. The template would then lookup in a front-end database what the actual strings are for those columns in that language.

Contrast this approach with the one that was taken. They were using HTML::Template, not Template Toolkit. They had a master template with the column specifiers. They then had a pre-processing step (kinda like compiling templates) which converted the master into 12 copies, one for each language. The actual strings were stored in a database that would be consulted when the templates were compiled.

I know which method I prefer ...

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

In addition, having your templates talk to a database doesn't violate MVC, in and of itself.

Yes it does. Should one layer change, the other will have to change. You should have some conduit/api where one talks to the other, such as a function or something. And that usually does not include putting DB stuff directly in your templates... unless you can show me an example where I'm misunderstanding your meaning. :)

Let's take a real-world example that I have worked on - a site that is available in 12 languages. Obviously, what language you present in is a V-layer issue. So, when you want to specify the column names for your report, you indicate in your code (either in the template or in the script) that you want the names for column 1 .. 5 in language $lang. The template would then lookup in a front-end database what the actual strings are for those columns in that language.

I rather the second oddly enough, but not have column names tored in the database. Use a properties file for that, and internally assemble them as template variables. But you know what, in the end, the devil is in the details of the technolgoies you are using.

The reason I'm used to not putting things like, display stuff in the database, particularly column headers, if that's what you mean, is because the technology I use for populating them into HTML, is the same one i use for email/smtp and desktop applications.

But this is all religon, we can argue for days. :)

Humma la beeba la seeba la booba la
Humma la beeba la seeba la bop

You know, if you used Template Toolkit, 90% of this code could be foisted off to the template

That still leaves 10% that I would have to deal with in my own code, so I would need a structure like this anyway. (Not to mention that I find doing anything fancier than straight substitution in template systems to end up as a frustrating exercise in creating a lousy language to avoid using a real one. No thank you...)

Also, although my example used DBI as a source and HTML as an output, this technique is not limited to those technologies.

Finally, one of the things I like about this techinique is that it centralizes the description and differences between all the columns in one place. If I want to rearrange columns in this scheme, I just swap hrefs around; using a template system, I need to change it in the template and in the loop.

I totally agree that templates are very handy when you have different people working on the code and the template. When it is just one person, I find it easier to have all the control in one place.