Re: rant on = qw(HTML::Mason Embperl Template etc) ;

[count0]

What about HTML::Template? Of all these types of modules for separating HTML from Perl, this seems to be the most successful at it (IMO).

HTML::Template templates even work with WYSIWYG editors. (when wrapped in html comments: <!-- <TMPL_VAR NAME="foo"> --> for example)
The html designer only has to worry about a small number of extra tags, which can be easily documented. These tags are even very non-Perl'ish, and eye-friendly to your average HTML guy/gal.

So, what is it about HTML::Template that isn't bringing it to the horizon?

[princepawn]

What about HTML::Template?

This is one of those questions that I would give 10 upvotes to if I could. You would think that since I wrote this node giving high praise to HTML::Template that I would have looked at iit harder before embarking on my glory run with HTML::Seamstress

What happened is I read perrin's seminal article on template system comparisons and ran across on called HTML_Tree, which at the time was on CPAN. But he removed his module from CPAN so I wrote an equivalent which was an improvement over it (as I saw it) in a number of ways.

Now, I plan to drop my HTML::Seamstress project and join the HTML::Template camp... I guess I opted for the vi of template systems even though I use Perl and Emacs, which are the swiss-army chainsaws in their respective classes... heheh.

But for the record, seamstress could compile it's template to executable perl programs. Also, seamstress methods are closer tied to HTML::TreeBuilder and HTML::Element so that HTML manipulations were programmatic and structural as opposed to string-based.

Also, I intentionally left out an include statement, so that this would be forced on HomeSite, Dreamweaver, what have you.

But you just have to do things slightly different with HTML::Template. But I feel that HTML::Template does offer what Seamstress offers albeit with a slightly different API. But given it's maturity (my god, the caching features!) and popularity it is best to join that school and continue the war again Template and Mason et al.

[princepawn]

actually, I take this back. There is no way I am going to drop HTML::Seamstress based on what I see going on on the HTML::Template mailing list.

forget it. Seamstress or bust

[kwoff]

One thing I didn't like about HTML::Template (maybe I just didn't understand it enough to come up with a clean solution) was the following.

I wanted to give the HTML developers a set of variables that they could use. They could pick and choose which of the set they wanted to display. It was a snippet of HTML to display the current weather, so they could show "wind speed", "wind direction", "temperature", "humidity", and so on.... I did something like:

$tmpl = HTML::Template->new('filename' => $TEMPLATE);
$tmpl->param('Temperature' => $current->{'Temperature'});
$tmpl->param('WindDirection' => current->{'WindDirection'});
$tmpl->param('WindSpeed' => $current->{'WindSpeed'});
...
print $tmpl->output();

and the HTML developers would ideally be able to select from those variables and use them like this:

<TABLE>
<TR>
<TD>
<SPAN CLASS="weather-temp">
<!--TMPL_VAR NAME="Temperature"-->&deg;F
</SPAN>
</TD>
</TR>
</TABLE>

But actually what I had to do was put ALL the variables into the template, and hide them as a comment, otherwise I would get some error:

<H3>Current weather</H3>
[insert HTML here using a selection of the variables below]

<!--DO NOT REMOVE:<!--TMPL_VAR NAME="Temperature"--><!--TMPL_VAR NAME=
+"PerceivedTemperature"--><!--TMPL_VAR NAME="R
elativeHumidity"--><!--TMPL_VAR NAME="WindDirection"--><!--TMPL_VAR NA
+ME="WindSpeed"--><!--TMPL_VAR NAME="Pressure"
--><!--TMPL_VAR NAME="Visibility"--><!--TMPL_VAR NAME="Icon"--><!--TMP
+L_VAR NAME="IconDescription"-->-->

...

and I just find that extremely ugly. What's more, if your variables are within a TMPL_LOOP (which I also did a list of news headlines, so in fact I found myself in that situation), then you have to put that blob of commented-out TMPL_VARs inside that loop.

Also I found that somehow this setup was confusing to the HTML designers, so I ended up having to edit the HTML anyway (maybe that's unique to my situation, though), thus smashing my dreams of never having to look at the HTML again.

[maverick]

There is an option to allow exactly what you're looking for. In fact it's one I ALWAYS have set. From the docs:

die_on_bad_params - if set to 0 the module will let you call $template->param(param_name => 'value') even if 'param_name' doesn't exist in the template body. Defaults to 1.

Change your constructor to

$tmpl = HTML::Template->new('filename' => $TEMPLATE,
                            'die_on_bad_params' => 0
                           );

And you'll be good to go.

/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

[kwoff]

Excellent, thanks.