HTML::Template consists of only a few control tags (loop, if, else, unless, include). There aren't any "commands in arbitrary places" as inline perl is not allowed. It has a very simplistic control structure; to illustrate this, let's look at a sample template.

Sample Template

<table>
  <tr>
    <th colspan=2>%bar%</th>
  </tr>
  <loop foo>
    <tr>
      <td>Type</td>
      <td>
        <if qux>
          %baz%
        <else>
          %baaz%
        </if>
      </td>
    </tr>
    <loop foobar>
      <tr>
        <td colspan=2>%barfoo%</td>
      </tr>
    </loop>
  </loop>
</table>
[download]

The above contains variable interpolation, an if-then-else statement and a nested loop structure that combine to create a table. The previous sentence is more complex than the template. And this is a good thing.

Even to an incredibly dense web designer (oops, that's redundant ;) this template shouldn't take too long to explain using a good example. To make things even easier on them and, in so doing, ourselves -- we can add the tags to their WYSIWYG tools. It took me 30min and a visit to Macromedia's online documentation to add 'drag and drop' tags and their accompanying editor widgets to Dreamweaver.

Template Syntax

Now I like this syntax, but maybe you don't. I don't like the default module syntax, maybe you do. That's okay. HTML::Template allows us all to have our own way through pre-processing filters. By passing the module a filter (sub ref or array of subs refs) you can regexp or otherwise process the template before it gets passed to HTML::Template proper. In this way you can do all sorts of fun things like change the syntax to whatever you desire. Performance is not an issue in this case unless you write horrible horrible regexps.

Perl Code

...
# invoke our template
my $t = HTML::Template->new(filename => 'foo.html', filter => \&filter
+);

# prepare an array of hashes for a loop
my @foobar;
push @foobar, { barfoo => $_ } for (1..4);

# one way to set an if statements control param
$t->param( qux => 1 );

# fill in our params
$t->param(
    foo => 'Camels of the World',
    bar => [
        { baz => 'Bactarian',
          baaz => 'Dromedary',
          foobar => \@foobar
        }
    ]
);

# output it
print $t->output;
[download]

Look Ma! No HTML! None. At all. Anywhere. Wonderful no?

Now it looks a little messy when hard coding the variables, but when you consider that you can associate the param() method with CGI's (or any other than functions like it) and that you can fetchrow_hashref (or create your own) from a DBI query...

My example is rather trivial, but you might be suprised at the power such a simple templating system has. If you subscribe to HTML and Perl in seperation, as you seem to do, then this module is the epitome of that philosophy.

Conclusion

Before you go off and write another new system be sure to take a long hard look at the current systems. You'll probably find one that's close enough to your philosphy that you can either adapt it through something like filters, or maybe even take an active hand and contribute to it.

Caveats

I'm writing this at 3:30am. ;)

I'm biased. I ascribe heavily to the philosophy behind HTML::Template and TT2. TT2 often gets a lot of evangalism though, so I chose to focus on HTML::Template. If I had to choose one, I think TT2 would win out; as "you get enough rope to hang yourself and half of the town with you" (mirod) whereas HTML::Template can keep you a bit to tight a leash at times. As always YMMV and CTRTFTJ (Choose the Right Tool for the Job).

I focused mainly on philosophy and syntax. There are lots of documents dealing with speed and fine tuning when you get to that point. Often people concentrate too much on that factor when your, my, and the graphic artist's workflow matter much more (in most cases)

See Also

• HTML::Template
• Template Toolkit 2 (TT2)
• perrin's article <-- I wish I had seen this earlier

(A nod to thpfft for his reply: thanks for your points, it's good to hear about experience from like-minded people.)

I did actually have a long look at HTML::Template. I knew that its syntax does not inline Perl and it in general is simplistic; I had even written a few templates using it as I pointed out. The default syntax is just too bulky and not visible enough in a mess of surrounding HTML.

(This is in reply to thpfft as well:) As I kept saying - I was almost about to start on my own templating solution. I couldn't believe noone would ever have felt the same need as I for a powerful but minimalistic language. (See my initial post, ".. it's amazing ..") My look at HTML::Template wasn't enough to discover filters as a way of making it do what I want although I remember seeing passing mention of that in the docs.

I posted here out of desperation - I didn't want to start from scratch and knew I shouldn't, but I couldn't see any way of avoiding it. Thanks for the replies everyone, your help is greatly appreciated :) Another look at HTML::Template it is. Don't worry, I'm not going to pollute CPAN with yet another templating module anytime soon :) (Or any of my code in fact. ;) Though come to think of YATM would be a good name. Hehe.)

Sidenote: performance is not much of an issue in my case since the script is going to spit out static files. In effect it's a 'make' to be invoked via browser; I wish I could use WML, but alas, I don't even have a limited telnet login on the server, and I can't run it locally because I'm not the only one working on the site.

First of all, thanks for that article; it was a big shortcut in evaluating at least some of the available modules. Yes, I did read it - I am subscribed to the Perl.com Newsletter so I think I got to see it very soon. :)

HTML::Template and TT2 made it through my preevaluation. The final decision was taken mainly with respect to the fact that the script I'm writing is intended to work on a system with a barebone Perl5 and no way to install modules - as is the case with many cheap web hosts. HTML::Template only consists of a sinlge .pm - TT2 is no competition in this case.

Well then. I embarked in working with HTML::Template. But the syntax is not well readable - <img src="<tmpl_var imgfile>"> is bulky, the tag doesn't visually stand out against a page full of template HTML, and using the brackets within a tag irks me. There is no special case to deal with newlines around the <tmpl_*> tags, so you can't put them on a line of their own if you want the output to look neat and tidy. And <tmpl_unless> can get very tiring to write dozen of times.

The templating module I want would offer powerful interpolation syntax but not a bit more power in highlevel constructs than necessary. It seems there currently is no way to get one without the other. HTML::Template actually is the opposite of what I need, it offers relatively powerful highlevel constructs but only a very limiting interpolation syntax unless you enable globals in which case you end up with even harder to read templates.

I should mention that the processing model I want to implement is (by the terminology of that article) a very strict pipeline architecture that allows logic in templates by cleanly separating it back into the code:

1. fetch data, build list
2. run filters over list to provide the template logic; variables get changed, added, deleted etc per record here
3. interpolate data into template

Now, you could say TT2 allows me to do it my way even if it offers more power than I want. But besides being awkward to use when you cannot install modules, to me it feels like "the tail wagging with the dog" as they say in Germany. Total overkill. I do not need a module that comes in 20-odd files incl XS, compiles my template to interpolate it, and can make coffee and bake cake to boot.

I was seriously about to go with CGI::FastTemplate - small, simple, clean concept written in a no-installation-required single Perl-only module. Except I had written something very similar myself for a previous (unspeakbly ugly) script and have come to despise the templatelet mess it reinforces. My only extra requirement beyond interpolation is just enough intelligence in the module so I don't end up with dozens of 30 byte template files.

Between my first reply and this one, you should have a very clear idea of what I want :) Say I wanted to modify an existing module rather than writing one from scratch. Where would you propose that I start?

I still don't understand the "this module is too powerful for what I want" argument. Isn't Perl itself too much power for most of the tasks we use it for?

That said you should really have a look at Text::Template. Granted its name does not include HTML, but it works really well for it anyway.

There was an interesting discussion about it on the TT mailing list, look for the "Pros and Cons vs Text::Template" thread. TT2 advocates had the same basic argument you have: they want a "crippled" templating language. Caching seems to me a better reason to choose TT2, but as they say YMMV...

One of the main issues with homegrown templating systems compared to popular packages available on CPAN such as TT2 or HTML::Template is the performance: most writers of homegrown systems focus on the syntax, not on performance: parsing speed, compiling to Perl, caching, all these are hard to get right. A homegrown system with a simple parser written in Perl using regexes might do a fine job but will offer poor performance under heavy traffic.

HTML::Template and TT2 made it through my preevaluation. The final decision was taken mainly with respect to the fact that the script I'm writing is intended to work on a system with a barebone Perl5 and no way to install modules - as is the case with many cheap web hosts. HTML::Template only consists of a sinlge .pm - TT2 is no competition in this case.

Hmmm... if you can install one module, why can't you install 20? I would expect this to be an all or nothing situation. If you can drop one module in your local directory, you can drop all of TT there.

I embarked in working with HTML::Template. But the syntax is not well readable

I'm not a fan of that syntax either. I definitely prefer the aesthetics of the TT syntax.

There is no special case to deal with newlines around the <tmpl_*> tags, so you can't put them on a line of their own if you want the output to look neat and tidy.

TT handles that, as do some of the others.

The templating module I want would offer powerful interpolation syntax but not a bit more power in highlevel constructs than necessary.

But no one is twisting your arm and telling you to use the full syntax of TT! Just use the part you want. If you find out you need more of it later on, it will be there for you.

1) fetch data, build list
2) run filters over list to provide the template logic; variables get changed, added, deleted etc per record here
3) interpolate data into template
All non-trivial modules I have seen try to integrate step 2 and 3 inside the template.

Hmmm. I don't think I understand these steps. The pipeline model is all about doing all of your data munging before running the template. The template only has display logic in it, and doesn't modify any data.

Now, you could say TT2 allows me to do it my way even if it offers more power than I want. But besides being awkward to use when you cannot install modules, to me it feels like "the tail wagging with the dog" as they say in Germany. Total overkill. I do not need a module that comes in 20-odd files incl XS, compiles my template to interpolate it, and can make coffee and bake cake to boot.

The XS is optional, of course. TT is fairly big. However, size is only a problem when it does not fall within your required limits for disk space, RAM, speed, and ease of use. I don't use half of the capabilities that TT provides, but I love the fact that when a designer comes to me and says "I want to display these search results in two columns" I can say "Here's the TT table plugin" and not have to write it myself. I've had experiences like that over and over with TT.

Back when I was a Perl newbie, I did write my own templating system. I actually wrote a couple of them. (In my defense, TT didn't exist then.) I started out really simple, but I ended up with a mess because people kept requesting features like columnizing lists, or slightly fancier boolean conditionals, or date formatting, etc. That's why I get so suspicious when people complain that the existing modules have too many features.

I was seriously about to go with CGI::FastTemplate - small, simple, clean concept written in a no-installation-required single Perl-only module. Except I had written something very similar myself for a previous (unspeakbly ugly) script and have come to despise the templatelet mess it reinforces.

Glad to know I'm not the only one who feels that way.

Say I wanted to modify an existing module rather than writing one from scratch. Where would you propose that I start?

The closest to what you are suggesting is Text::Templar, but I don't know how easy it would be to extend.

if you can install one module, why can't you install 20?

Simply due to convenience and cleanliness. Imagine what a cgi-bin looks like after you install four of five scripts which all require their own set of 30 external files. Even if the extra files go into subdirectories, it looks a lot better, but it doesn't look good. I'd really like to telnet in and do 'su -c perl -MCPAN (..)', believe me. :-/ But I do not have that convenience in this case, and even if I did, others might not, in case I release the script. Requiring a specific multilevel directory tree to place the modules in is going to make installation for less adept users painful also. So the fewer extra files I can get away with, the better. HTML::Template is perfect in that regard, a single file that I can rename and then manually require/import if need be.

But no one is twisting your arm and telling you to use the full syntax of TT! Just use the part you want.

I would - but again, see above paragraph.

I started out really simple, but I ended up with a mess because people kept requesting features like columnizing lists, or slightly fancier boolean conditionals, or date formatting, etc. That's why I get so suspicious when people complain that the existing modules have too many features.

I am aware of that trap and am not going to fall for it. I want the interpolation to provide enough flexibility to implement these features on the template's end (rather than the templating module's) without the template language providing elaborate control constructs and that should be doable with a fancy variable dereferencing syntax.

The closest to what you are suggesting is Text::Template, but I don't know how easy it would be to extend.

I will have a look.

So far I fetched HTML::Template and found that getting it to comply to my wishes is very possible by just wrapping a layer of own routines around it. Basically I lie to the module about my data and feed it through the back door; the main dirty trick is that I use the association mechanism to make it think that [foo.bar] is an actual variable while my param() silently derefences that into $t->{foo}->{bar}. Anything but conceptually clean - but it works well.

Edit: I had a look at Text::Template - that doesn't at all seem to be like what I want. It uses Perl embedded into templates, whereas I want an absolutely minimalistic minilanguage. Am I missing something?

the tag doesn't visually stand out against a page full of template HTML

I write my html in lowercase and my TMPL code in upper case. Stands out a mile, e.g.

    <h3><TMPL_VAR HEADER></h3>
    <h4>please log in:</h4>
    <form action="input.pl" method="POST" name="mainform">
    <input type=hidden name="Action" value="
<TMPL_VAR FUNCTION>">
    user name: <input type=text width=30 name="UserName" value="<TMPL_
+VAR USER_NAME>"><BR>
    pass word: <input type=password width=30 name="PassWord" value="<T
+MPL_VAR PASS_WORD>"><br>
<TMPL_IF LOG_IN>
    <h4>if you don't have a user name, then you'll need to <a href="in
+put.pl?Action=StartRegister">register</a><br>and if you've forgotten 
+your user name or pass word, <a href="mailto:<TMPL_VAR EMAIL>">email 
+me</a></h4>
</TMPL_IF>
<TMPL_IF REGISTER>
    security code: <input type=text width=30 name="SecCode" value="<TM
+PL_VAR SEC_CODE>"><BR>
    if you don't know the security code, chances are you didn't get an
+ email from me inviting you to be here... if you'd like one, please <
+a href="mailto:
<TMPL_VAR EMAIL>">email me</a>
</TMPL_IF>
[download]

Having said that, I have some sympathy with your aesthetic reservations about >>! But seriously, I'd like to add my voice to those that say HTML::Template pretty much fits the spec you laid out. Certainly as I've found more and more imaginative ways of configuring the param() method, I've found there's no structure I want to use that it can't handle with ease. And the bonus is, it lets me do the complicated stuff in regular perl, not some strange module dialect.

§ George Sherston