I've been using this module for about 6 years now and I probably have over 100,000 lines of HTML::Template templates code.
This module is easy to learn and use... and that's why it sucks.
The simplicity tricks you into choosing to use it, but you quickly hit its limits. Unwilling to learn better templating systems, you continue to use HTML::Template, nesting a ton of <tmpl_if>s to solve fairly common logic situations, because there's no <tmpl_elsif>, and willingly burying yourself into an unmaintainable tag soup.
There's also no surrounding white-space handling, so if you choose to write readable documents at 80-char width, your output will end up with dozens of empty lines all over it.
In summation, if you want a quick one-off template generation that has virtually no learning curve, go for it, but if you're choosing something to write many HTML templates in, avoid this module—and I speak from experience.
If you're stuck with a bunch of HTML::Template templates, take a look at HTML::Template::Compiled. It offers more features and seems to work well as a drop-in replacement to HTML::Template.
I really hate this module: use Template Toolkit. SGML based template languages are stupid. Just put take a look at the example from HTML::Template::Expr
<TMPL_IF EXPR="banana_count > 10">
Imagine if that was burried in HTML:
a) it wouldn't stand out
b) when you found it you would have to mentually parse out the tokens in order to realise one of those greater-thans is literal, the other closes the token.
What a nightmarishly bad idea. Look at the overly complex TMPL_* garbage where TT just uses clean syntax.
TT is cleaner, easier to read, and has more functions. Look at WRAPPER in TT -- html::template just can't do that type of stuff.
This is really an archaic template system that is showing age in all kinds of very bad ways.
I've used HTML::Template in a couple of jobs and found that as soon as you leave non-trivial templating it becomes extremely limiting and requires more and more data munging in the code using the templates in order to get everything into a hash of arrays of hashes shaped data set.
For simple templating such as trivial email, cgi scripts or configuration files it works very well.
In almost all non-trivial work however it is extremely limiting and is best replaced by Template Toolkit. I've used both, and will no longer use HTML::Template at the start of the project because it can involve so much work moving later when you are stuck with the mess required to acheive anything non-trivial with HTML::Template.
In summary, 80% of the time you want to use Template Toolkit instead, and the other 20% of the time, H::T doesn't offer any benefits over TT.
HTML::Template is allegedly fine for simple stuff but rapidly gets unmaintainable when you want to do anything more complicated. Maybe you're only doing simple stuff now, but chances are, later you won't be.
Problems I've come across resulting directly from H::T's design decisions in a large templated application include:
* No dot notation, so you end up flattening your data structures. We prefix related keys like "USER_" instead of being able to pass in a hash "USER" and work on that.
* No expressions, so you can't, say, select a tab if its name is the same as another variable. Instead you have to preprocess the list on the perl side and add a variable "selected". If you want to highlight every other row in a list then preprocess in Perl! After all, if you wanted separation of business and display logic, you'd use a templating system.
* No dot notation means you can't handily use objects, hashes, arrays.
* Lack of object access or plugins means you can't easily do localisation in the template and instead have to preprocess in Perl.
* Filtering isn't plugable. You have "ESCAPE=HTML" and "ESCAPE=JS" and, er, that's your lot. I guess you could preprocess in Perl.
* The default (and therefore most commonly used) tags are <> which means it gets highlighted wrongly by most editors, and ignored by the web browser if viewed un-processed, making it harder to debug. Yet the syntax isn't valid XML.
Some of these deficiencies are fixed by HTML::Template::Expr (which apparently the author disapproves of) and various modules which add dot notation, expressions, plugins and the like.
Or you could just use Template::Toolkit which is as easy to use for the simple stuff, and infitely less frustrating for everything else.
This module does what it's supposed to do very, very well. It's well documented and simple to use. And if you hate complex logic in your templates this is a good place to go. Logic is severely restricted.
I however often have complex presentation logic, and I find when using this module I end up writing a lot of perl code to fix the template display . When I create a separate module just for HTML::Template display logic the temptation to add business logic in is great. And if someone succumbs to that temptation then you are back to HTML Mason style situation -- only instead of mixing your biz and presentation logic in an HTML page, you are doing it in a perl module. Anyhow I find that using a larger template language like Template toolkit's allows me to cleanly separate business and presentation logic - allowing me to do presentation logic in the presentation layer, and biz logic in the perl modules.
Great module! It lets me separate my code from my HTML. The template syntax is straight forward. I like the fact that it can do some introspection (see query() method). I only wish it could handle sending objects directly to the template out of the box.
HTML::Template does exactly what I need. It allows me to seperate the presentation from my code and isn't at all complex. It has a simple syntax with easy to understand documentation and examples. It gives you just enough of what you need without so much that you'd need a book to learn it thoroughly. There are also HTML::Template extension PMs you can find on CPAN that will let you integrate some degree of code or evaluations and calculations in your templates (if you're into that sort of thing).
HTML::Template was perfect for pulling the presentation part of my existing complex and details project into its own layer without making any sacrifices or major changes in the code itself. I've looked at HTML::Mason and Template::Toolkit and would certainly consider them under different circumstances, but for my needs HTML::Template is *perfect*.
This is an excellent module for truely separating HTML design from perl coding. From reading the other reviews, I agree that it is not as complex as Mason or Template Toolkit, but that is what I like about it. Keep it simple! HTML designers can quite easily pick it up without knowing anything about programming. It is a great templating system from beginners to advanced web developers who want to keep their perl code clean and their web sites easy to maintain.
Note: this review applies to earlier versions of HTML::Template.
This is an excellent module. This one has made web application development much easier for me.
The only downside is with using simple loops with one value. It seems like a kluge to have to convert an array into a hash. It's also awkward to specify a "default" option for select lists. These are both common issues that I think deserve implementation in the module.
HTML::Template does exactly what I need and does it well. Can't ask for anything better than that. Extremely easy to use, fast, mature, stable. If your templating needs do not extend to one of the heavyweights (Mason, Template Toolkit), then you really can't go wrong with HTML::Template.
HTML::Template is a worthwhile tool for templating, and developing web applications, especially when used in conjunction with CGI::Application. However, since the templating language is light-weight, you may likely run into walls when attempting anything fairly involved (i.e., 'ELSIF' is missing). HTML::Template is useful if your needs are not too great, otherwise you might take a look at HTML::Mason.
HTML::Template is more than just a Perl module: it's a very simple and very clean templating syntax, perfect for an easy separation of code and presentation. And it's also available in other programming languages (Java, PHP, Python, Ruby and even Lisp), which is a real plus because you can share the same templates between web designers, Perl developpers and (for example) Java developpers.
This module enforces a useful seperation of code and design by providing a minimal amount of template logic in the templates. Easy to learn, built for speed, and very powerful. I use it quite frequently, even as template solution for non-HTML text. It is mature, with several extension modules available, plus ports to several other programming languages. Highly recommended.