1. You can output different stuff, depending on user choices. For example, PDF::Template takes the exact same data structure as HTML::Template, but makes a PDF.
2. You can use different languages, or even co-brand your site.
3. You can have one person maintain your HTML and one person maintain your code. HTML::Template templates are even maintainable using Dreamweaver, Frontpage, and the like.
4. Because your code is focusing solely on code and your display stuff is focusing solely on your display stuff.
5. Because all the monks who have more experience than you are telling you to.

In addition to these reasons, I like using templates because I can edit my HTML comfortably in Mozilla Composer or Emacs HTML mode, with syntax highlighting, HTML validation, etc.

Good points. I'm especially fond of points 3 and 4.

Also, why not ditch CGI.pm totally and use CGI::Simple to get a little performance boost?

--
"To err is human, but to really foul things up you need a computer." --Paul Ehrlich

"... why add the complexity of a separate HTML template ..."

Because someone added the complexity of an HTML coder to your project. Whenever i write a small app for myself, i usually just pick CGI.pm and be done with it, but anything that involves a team, i use a templating system. I started out with HTML::Template and we use HTML::Template were i work, but must confess that Template Toolkit is very fun stuff.

$sth = $dbh->prepare("select title,width,height,param,alt from menu");
$sth->execute;
$tmpl->param(menu => $sth->fetchall_arrayref({}));

print header, $tmpl->output;

__DATA__
<tmpl_loop menu>
<span class="mitem">
   <a title="<tmpl_var title>" href="?a=<tmpl_var param>">
   <img height="<tmpl_var height>" border="0"
                    src="i/<tmpl_var param>.png"
                    alt="<tmpl_var alt>"
                    width="<tmpl_var width>" />
   &nbsp;<tmpl_var param>&nbsp;
   </a>
</span>
</tmpl_loop>
[download]

1. to print the header
2. to fetch the params
3. to create form elements

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

That's why I created HTML::Template, and that's why I still use it today.

-sam

I think you are using HTML::Template in the same way you would CGI.pm, ask yourself why?

If you want to write the HTML in terms of programatically generating HTML, then use CGI.pm. But if you want to separate the logic from the presentation, then use HTML::TEmplate as a templating system, not as a poor substitute for CGI.pm!

I build menues on my sites too. But I actually write them in different ways. So I can maintaint hem OUTSIDE the Perl files.

jdtoronto

Your CGI example uses a loop to output the data from a @menubar array, but the same data is hard-coded in your HTML::Template example. You could have kept the array there and modified a lot less code:

my @menubar = ( . . . );
my $template = HTML::Template->new(
        filename => 'menubar.tmpl');

$template->param(MENUBAR => [
        map {{
                title  => $_->{title},
                width  => $_->{width},
                height => $_->{height},
                param  => $_->{param},
                alt    => $_->{alt}, 
        }} @menubar
]);
# Or maybe just:
#$template->param(MENUBAR => \@menubar);
print $template->output();
[download]

Notice that with CGI.pm, you're doing two things: specifiying what tag to use, and the data to place with that tag. That's one thing too many. In HTML::Template, you're only specifying what the data is, and you let the local HTML monkey worry about what the actual tags are.

As it happens, since I work at a company with a rather small IT staff, the HTML monkey for my projects is usually me. I still use HTML::Template because it is quite likely that the UI for my projects will change. We have people here who are much better at design then I am, but who don't know much programming. So I stick with the template so that they don't bug me just because the UI needs to change :)

I'm working on a big complicated system in which I've outputted lots of HTML with CGI.pm (writing tables is still almost irresistibly compact with CGI.pm).

But despite that we've never had a dedicated HTML person -- it's still engineers writing both HTML and doing the programming -- I've regretted it, and have been very happy we're almost through migrating to a template solution.

Outputting the HTML programatically makes it too damn easy to do things that'll bite you in the butt... like having a given page ultimately made from bits of codes scattered across your script and multiple modules, such that wanting to change a given something about the page can create a headache first in just finding where to make the change.

If you want to make comprehensive changes to your pages' appearance, where you have to look is isolated in advance with a templating system.

Having them intermingled makes it easy to break program logic when you just wanted to make a change to the display elements. You'll probably find and fix the problem readily enough, but probably could have avoided it all along with a templating system in which, when you're modifying, testing and debugging how something looks, you know that's all you're doing.

Plus all the good advice you've already heard about what happens when an HTML person is added, the advantages of using an HTML editor, etc., etc.

Unless you're sure the program's a one-time knock-off for only your own use, writing your HTML with CGI.pm is false laziness.

(I detest CGI.pm, too, it's not just templating toolkits. It's one of the things I'm good at. Detesting.)

Lately, I've started to tinker with doing HTML in Perl. It's rather fun, actually. I do thinks like:

body {
  div {
    { class => 'content' },

    q{Text content},
    table {
      { width => '100%' },

      row {
        cell {
          ...
        },
        cell {
          ...
        }
      }
    }
  }
}
[download]

(Ok, so this doesn't really answer your question at all. Sice the templating guys are bound to do so though, I just thought I'd share. Sorry.)

It's been many years since I worked on a project where the HTML was done by the programmers, and I would still prefer templates for various reasons. However, if generating HTML programmatically is your bag, you might like higher-level abstractions like what Bivio does.

I think you're exaggerating the part about needing to change your data format. Template Toolkit can deal with pretty much any data structure you pass in, and doesn't need in-line Perl to do it.

I think you're exaggerating the part about needing to change your data format. Template Toolkit can deal with pretty much any data structure you pass in, and doesn't need in-line Perl to do it.

You're right, that was unfair. Still, you end up catering to templating toolkits' notion of control structures no matter what, be they rigidly formatted data structures or a separate specialized in-line language. I'd like to code my control structures in Perl.

dragonchild made the excellent point (#4), but just to elaborate, separating your design code follows the recognized MVC paradigm (one Google doc that partially explains it), which is an excellent methodology to follow when programming (unless you're doing some simple "Hello World" kinda stuff).

I'll also make another quick point while I got the podium: be careful when turning over your HTML::Template files to DreamWeaver web-monkeys - in my experience, DreamWeaver has a tendency to muck up your files with its notion of correct HTML ... for example, template tags within a string or other tags:

<a href="script.cgi?<!-- TMPL_VAR NAME="foo" ESCAPE=URL -->">Link</a>
<input type="checkbox" name="option" value="test" <!-- TMPL_IF NAME="s
+elected">SELECTED<!-- /TMPL_IF -->>
[download]

I forget (or I'm so scarred that it's been purged from my recall at the moment) what they get turned into ... it ain't pretty, though. I haven't taken the chance to sit down and go through DreamWeaver's preferences - I believe there's something in there to turn off it's "corrective" nature, but I always make a backup and then compare the two files after the web-monkey is done.

Peace,

Jason

in addition to what everyone else has pointed out, HTML::Template has the advantage of being relatively language independent. the template syntax isn't tied to perl, and there are implementations written in python, php, java, and probably other languages. so if you ever decide to switch languages for the backend, you don't have to port the templates. i've successfully converted apps from perl to python and vice versa without touching the template files.

i've also used HTML::Template to make 'skinnable', or highly customizable web apps. you just throw up a quick admin interface that lets users (or admin users at least) edit the template files that generate content directly through the browser. i have, eg, a quiz/survey/poll engine that uses HTML::Template. it's designed to plug into any site or web application that we need to plug it into. using templates lets us easily customize each instance to fit in graphically.

and HTML::Template's ability to hook into the CGI and DBI modules, when used properly, reduces a lot of the extra overhead.