HTML::Template Vs Template Toolkit

[Anonymous Monk]

Hi,

Could you please differentiate between HTML::Template and Template Toolkit modules? I am new to Perl, is there any advantage in using Template Toolkit module compare to HTML::Template?

Thanks

[moritz]

In general Template Toolkit is more expressive than HTML::Template. That sounds like a good thing at first, but it tempts you to put too much logic into the template.

If the HTML::Template route seems appealing to you, you should also look at HTML::Template::Compiled, which adds a a bit of convenience and caching.

[Your Mother]

Template Toolkit is an an entire mini-language which can lead to bad practices and runs slower than most, if not all, of the other template kits while HTML::Template more strictly adheres to the purist idea of what a View RFC:SHOULD be. That sounds like a good thing at first but it hinders you, lacking all but the most simplistic loop controls and unsweetened include directives; and speed in the template layer is rarely a real issue in the full stack of a live web application.

If the Template Toolkit route is appealing to you, you should know that it includes its own caching and dozens of other really nice affordances which will make your development easier, more fun and, if you can restrain yourself from going PHP on your templates, plenty manageable.

:P — see also Template::Alloy for Template (TT2) compatible syntax with some of TT3 too.

If you do want to go PHP on your templates, see Mason. But I keed!

[dsheroh]

Once upon a time, I used HTML::Template for all my projects. Then I tried Template Toolkit and I've never looked back.

So, why do I prefer TT so heavily? Mainly because I use templates to decouple code from presentation and HTML::Template required me to build up huge swathes of code to provide every last detail that would appear in the presentation. When using TT with object-oriented programming, I can just pass off (usually) either a single object or a list of objects to TT and the template can inspect the object's properties to collect the information it needs. If a new property is added, templates have immediate access to it without the additional shim of adding code whose sole purpose is to make that additional data available for presentation.

Does this mean that I can also put method calls into a TT template? Yes, it does. But I don't. I don't turn on TT's EVAL_PERL option, either. I do put logic in my templates, but it is strictly display logic, which is a part of the presentation, not application logic. And, no, I can't say that I've ever felt particularly tempted to do otherwise.

[tobyink]

A variant of Greenspun's tenth rule says that any sufficiently mature HTML template language becomes a clunky, ad-hoc variant dialect of its host language. Smarty exposes pretty much all the power of PHP with an even dumber syntax. TT2 does the same for Perl.

This is what I don't "get" about template languages. If I want to write my templates in something Turing-complete, then why would I want to learn and use the clunky, ad-hoc language? Why not just write my template in Perl, a language that I already know?

This is what I like about Text::Template, and why I choose it over TT2 and friends on the rare occasions I actually need templates. Rather than inventing a new template language, it simply provides a mechanism for embedding Perl in strings, and evaluating those strings.

More often though, if I'm outputting HTML rather than treating it as templated text, I tend to prefer to build it up as a DOM tree and then serialize it.

[sundialsvc4]

I personally believe that the main pragmatic issue, which lead to the development of more elaborate pure-templating languages such as TT, is that “the user interface is the one thing that is subject to the most Change For Change’s Own Sake.”   Say, by the marketing department.   The lead salesperson (who also happens to be the owner’s daughter ...) is worried about her commission, and she’s convinced that the reason why people aren’t buying is because the web-site doesn’t look like Competing_Site_X.   So what this means is that the presentation-layer of the site is going to change ... a lot ... frequently ... and for what are basically non-technical reasons.   And we all know what happens when the same code that does useful work keeps getting reworked ... code, like wrought iron, becomes more brittle the more you bend it.

TT compiles your template on-the-fly to Perl code and may cache that generated code on disk to avoid constant recompiling.   It has become very elaborate because it is designed to be arm’s length from the non-presentation side.

These are issues that you, as the designer, are going to have to Meditate upon.   There are many templating systems, and templating-system philosophies.   All of them are in-service and working as designed.   My preferences might be easy to guess from this, but I think that there is no bright-line rule.

[tobyink]

That's an argument for separating the "logic layer" from the "presentation layer", but not an argument specifically in favour of "template languages".

[sundialsvc4]

I would say rather equitably that you should just take a serious look at both ... and to consider carefully the particular requirements of your project and perhaps the preferences of you and your team.

[hippo]

One distinction which I find important is that HTML::Template is for HTML, whereas TT2 is a general-purpose templating system. I've used the latter for HTML/XHTML, XML, CSS, LaTeX and an assorted bunch of weird and wonderful proprietary data formats. Given that TT2 does all this, I haven't felt any great need to learn HTML::Template's syntax as well.

If all you will ever want to produce are HTML templates then this probably won't matter to you, but my preference is for the more flexible tool.