On the shortcomings of HTML::Template
On the shortcomings of HTML::Template
WebGUI has shipped with HTML::Template for a long time. It's sort of the de-facto standard for Perl templates, and many users already have it installed. It has a simple syntax that is reminiscent of HTML tags, and can present simple data structures with a minimum of fuss. So, what's the problem? The first issue is the syntax: it looks like HTML. This is particularly an issue when you are templating an HTML page because it becomes difficult to visually separate the template parts from the markup parts. It also leads to constructs that look badly formed — for instance, the common
Now I have what appears to be an unclosed HTML tag sitting in the middle of my href attribute. To be fair, HTML::Template does allow a "comment" template variable style:
But this is hardly an improvement, and still looks like HTML. The second major issue with HTML::Template is its generally poor handling of data structures. At first glance, it seems to handle all three of the core Perl datatypes admirably: scalars become TMPL_VARs, arrays become TMPL_LOOPs, and hashes become... wait a moment. Don't I send hash references to templates all the time?
Well, not really. HTML::Template has no real way to talk about hashes (or scalars, depending on which way you look at it). A hash is a context. If you want to display some kind of associative information, you have to munge your data into a TMPL_LOOP (an array reference):
Then you get to loop through this in your template:
It also has no way to talk about raw values inside a loop. I cannot send [1,2,3,4] to HTML::Template. Each value must be a hashref with named variables, or it is useless to me, and thus it becomes:
This can become a real pain for more complicated data structures, and you shouldn't have to do it. A template should take whatever data I give it and extract the useful parts into a view. I shouldn't have to write code to prepare it for the template engine! Luckily for us, Perl (both the language and the community) has this abiding maxim: there is more than one way to do it. WebGUI tries to share this attitude, so ever since somewhere in WebGUI 5, you can plug in a different templating engine. The only alternative (by default) is Template Toolkit, but all that is required to plug in your template engine of choice is a new subclass of WebGUI::Asset::Template::Parser. Add your new subclass to your WebGUI config file (under the templateParsers variable), and now you can use whatever template engine best fits the task at hand. As a point of comparison (and to encourage you to make use of the already available and excellent Template Toolkit), here is a brief look at the Template Toolkit syntax:
Template Toolkit syntax doesn't look like HTML, and supports much richer data access than HTML::Template, far beyond the simple cases we've covered here. And if you have another templating engine that you prefer, it's almost trivial to leverage it from WebGUI. There is more than one way to do it!
Re: On the shortcomings of HTML::Template·
Having used both extensively, I find that every time I resort the HTML::Template rather than TT I absolutely miss the ability to build in-template value comparator conditionals. Being able to build a page and rely on branching based on an incoming single value is a dream. H::T requires the developer to build a bunch of true/false template variables, each one with a unique name and usually very verbosely defined. This latter issue makes typographic errors or even just mistaken parameter transcription a much more frequent occurance. TT can be made very obtuse, just like Perl itself, so care must be taken. However, I've never regretted implementing TT over H::T because it makes development easier, and is at least as understandable to design critters when done carefully. Stephen Opal |

