HTML::Template vs. Template::Toolkit vs. ??

[Rodster001]

I have been using HTML::Template for years and for the most part have been very happy with it. I like how it is simple, keeps the logic OUT of the templates and does a great job of separating code from design. I have never had a performance problem that I couldn't solve.

But, I have noticed that HTML::Template has not been updated for a couple years and was wondering if it had been abandoned because people are favoring something else (or if it is just that stable!).

I took a brief look at Template::Toolkit and at a glance it seems to work *nearly* the same way at the basic level. But, for example, the block directive "foreach" seems to take some of the programming logic out of the program and into the template (I'm not a fan of that, I don't use HTML::Template::Expr).

Oh man, after re-reading this I could see this thread turning bad. I am not trying to start a flame war. I really just want to know what people are using and if there is any solid reason (other than personal opinion) to consider switching from HTML::Template.

Thanks for your insight!

[CountZero]

Strictly Template::Toolkit here because it allows you to put logic inside or outside of templates as you like it. I use DBIx::Class a lot and I can just pass a recordset-object to the template and have the template loop over it and do all kind of things to it, such as sub-totalling, adding color depending on some field-values, ....

I mainly use it on non-HTML templates: the perl-script gets the data out of whatever storage it is in, hands it to the template which writes a nice LaTeX-file which then gets rendered by the TeX engine into a über-nice PDF report.

[jeffa]

I use HTML::Mason these days, but only because i have used it now at 3 places of employment and have had the opportunity to work with some extremely bright developers at 2 of those places. I think reality has shown that the concept of passing off templates to HTML designers just isn't very practical. I have found myself having to massage their HTML into the web site regardless of how well the data was separated from the presentation. I am not saying it's a bad idea -- it's just an idea whose time already seemed to come and go.

[metaperl]

jeffa do you have an example of "having to massage their HTML into the web site regardless of how well the data was separated from the presentation."

I dont understand what you mean from a practical perspective.

[jeffa]

We tend to get a PDF that represents that web page. It's usually up to us to turn that into HTML. Since this HTML is then sliced up and component-ized, it becomes very cumbersome for an HTML designer to pull the pieces together in their environment. So, these days I only have separation concerns that address simple organization -- not work flow.

Most environments just aren't as simple and self-contained as what CountZero describes. I wish they were.

[MidLifeXis]

Display logic is also not the same as business logic. The part of using a template system that has bothered me the most, and caused me to switch to T::T, was that I had to still massage the data so that the display layer could deal with it in an efficient manner.

Since I have switched to T::T, I now leave the data in a structure that represents it well, and let the display logic handle the translation into what it needs. Now the data generation is (fairly) stable, and presentation is handled in the template.

That being said, I agree with jeffa's comment above that the templates are still code, just with limited access to the data provided.

[zby]

I used to use TT - but now at work I am back to HTML::Template. For me it is a step back - mostly for one thing: with TT I can pass an object or other structure to it and I know that I'll be able to display it, with HTML::Template I need to convert the data to the format acceptable by the templating engine. In other words with TT it is like "fire and forget" - just remember to pass all info needed, with HTML::Template you need an additional step.

[LanX]

HTML::Template::Compiled is active, heavily supported, compatible to your old stuff and the fastet you can get (-> Re: Template Toolkit Cache )

[monarch]

Mason and Template Toolkit basically generate Perl code. HTML::Template, on the other hand, is a pure separation of template from code.

Should you be concerned if the module hasn't been updated in some time? Only if you find yourself worrying when the IPv4 protocol is still in use without any significant changes for some time. Only if you find the cron daemon a bit outdated for your liking.. My point is that if something works and does what it says on the box then stability is generally a good thing.

Updated: grammatical corrections.

[metaperl]

HTML::Template, on the other hand, is a pure separation of template from code.

It is rather pure (moreso than tt/mason), but Petal is purer and HTML::Seamstress is even more pure.

[SouthFulcrum]

I have no business comparing the various template modules as I've only always used Template Toolkit. However, that fact stands to say I've never thought "This is annoying, maybe I should look at the other templateing engines." I realize that might not sound helpful, but TT is wonderful and I don't see it being "abandoned" anytime soon (though I wouldn't assume HTML::Template is actually "abandoned").

If you like and are comfortable with HTML::Template and hear back that it is "just that stable", then whatever. However, Template Toolkit has improved my quality of life. It is as powerful as it is usable. TT (via plugins) is not just for HTML.

[moritz]

I started out with using HTML::Template, it was the first template system that I knew, and I liked it.

I then read a Catalyst tutorial, and that used TT. I really liked it, and started using TT.

My first doubts about TT came when realized that it missed a killer feature that HTML::Template had: the default_escape option. It really makes all your worries about cross-site scripting go away.

When I tried to make my web apps "Unicode Safe" I moved them from HTML::Template to HTML::Template::Compiled, which has the open_mode option to get rid of my UTF-8 worries.

I started to write more things with Catalyst, DBIx::Class and TT, and came to the conclusion that this model, while much more powerful than HTML::Template + $otherStuff, tempted me to do bad things, like issuing DB queries from within the template (if you don't know what's bad about this, just think of how you'd handle error cases).

So these days I mostly use HTML::Template::Compiled again.

[Anonymous Monk]

FYI, Template::Stash::HTML::Entities does what default_escape does.

[tinita]

what I don't quite like about that is, that if you need unescaped data, you have to decode it, so that produces extra work (encoding and directly after that decoding again), while in HTML::Template(::Compiled) no escaping at all happens if you use ESCAPE=0.

[moritz]

Thank you, that looks nice (although I don't see an example of how the decoding works). The last time I asked, nobody had a convenient answer, so I guess things are improving still (which is a good sign).

[Anonymous Monk]

I'm currently using HTML::Template and having some Unicode issues. For example a parameter of '\x{a3}' gets converted to '\x{c2}\x{a3}' in the return value of 'output' - that is the individual UTF-8 bytes appear to get interpreted as Unicode code points. For reference this is a pound sign and the Unicode code point is '00A3' and the UTF-8 hex is 'C2','A3'.