Comparing HTML::Template::Compiled's compatibility to HTML::Template

[markjugg]

I was excited to see the arrival of HTML::Template::Compiled. It brought a number of additional features I was I was interested in, while still holding to the HTML::Template philosophy from my perspective.

I did my own analysis to check the compatibility, which I'm sharing here in case it's of interest to others.

I wanted to see how HTML::Template::Compiled (HTC) would do when run against theHTML::Template test suite.

To test this, I copied over the test suite from HTML::Template 2.8 (just released), and did a find and replace of HTML::Template to HTML::Template::Compiled.

I expected some failures, because there are a few documented differences.

I was surprised by the results-- HTML::Template::Compiled passed all the tests but two kinds. One were the tests for "query()", which I don't use and is documented not to be implemented yet (but is planned). The other failed test was a brand new one added in 2.8, the "else else bug" test. This is really a test for how H::T responds to a bad template, rather than a feature compatibility test. HTC actually had a better response than H::T 2.7 did-- it died with a syntax error instead of silently allowing the bad token through.

As I reviewed the results, I realized too few tests failed. Or rather, HTML::Template is missing some tests in the first place. For example, HTC doesn't bother with "die_on_bad_params" (I haven't bothered with it myself in years). So, those tests from the H::T suite should have failed, but they didn't. HTML::Template has no tests for that.

HTML::Template::Compiled is an exciting project to follow.

Recently I worked to bring TT's dot notation to HTML::Template. Since HTML::Template doesn't support plugins, I first had to create a HTML::Template::Pluggable subclass to allow plugins, and then write HTML::Template::Plugin::Dot to add the functionality.

HTML::Template::Compiled as a feature like this built in, and I can load one module to use instead of three, and have better performance to boot!

While I expect to do further evaluation before deploying a major project with this newcomer, I do encourage others to evaluate this HTML::Template alternative.

[pKai]

Your praise is a nice Christmas present for tinita, IMHO.

One thing I like about HTC especially is the opportunity to make a dynamic include (reading the name of the file to include from a variable), something I saw repeatedly asked for for HT.

Of course I'm biased in this case, as I made the innocent proposition on the German perl-community board (where she is moderating) that such a feature would probably be nice.

Well, I wasn't disappointed; she implemented it the following days ;-)

[markjugg]

The responsiveness and openness to change on the part of the maintainer is certainly a "feature". I submitted a "wish" for HTC when HTML::Template 2.8 came out-- I wanted "default_escape" functionality in HTC as well. Within 24 hours, tinita had added it.

Mark

[esskar]

yes, my "girl friend" put up a very good template. it's pretty fast compared to other tempalte toolkits and actually it is fully compatible to HT during daily use. (I never used query function). And of course, she is really willing to fix bugs - i noticed that myself quite often.

PS: Love you, tinita. :)

[qq]

Just curious if anyone has benchmarked, or run the test suite against simonm's Text::MicroMason, which also compiles templates (HTML::Template and other flavours) to perl code?

[perrin]

FYI, nearly all of the popular ones compile templates to perl code. A sample run of the benchmark included with H::T::C on one of the machines at my office is here. Of these, both TT and H::T::C compile to perl code, with the difference in speed being about what I would expect from the difference in features. H::T compiles to an internal parse tree format, and H::T::JIT compiles to C code and then to a dynamic library.

[tinita]

quote from the mailing list:

By default, the benchmark tests creating a new Template object every time, which no one should ever do.

is the TT object guaranteed to stay in shared memory? if not, it might use a lot of memory for every single apache process. (i have a little memory benchmark in the HTC package, but it needs a clean-up, so at the moment I probably don't get correct results on how much memory a TT object consumes.)
HTC is designed to stay in shared memory (*), and it does the object caching itself, so the programmer doesn't need to take care of caching the template objects. this would be nice for TT, too.

update: ok, now I get your point - the TT object is not file specific. i'll update my testsuite, thanks =)

* except when using options formatter, filter or dumper - options which cannot be converted into written perl code at the moment