... using a here doc and xslt transforms for outputting html ...

In the last months or so I wrote a bunch of Perl scripts for compute cluster control - which do lots of wicked rsh's into a cluster an present nice html output to the coworkers.

I started out w/heredocs, then changed that to qq{..}-strings, then throwed the towel and used _{(sound on)} a nice little module called:

HTML::Template

This was a stunning experience, after (short) working through the details, I ended up with a HTML-File per script (same name as the script + .htm) and several very clean and easy readable Perl scripts.

The proloque to the action would be identical across the scripts, in my case that's sth. like:

   ...
   $scriptname = ...                            # the scripts name
  (my $srv = $ENV{SERVER_NAME}) =~ s/\..+//;    # where are we now
   my $srvloc = "/srv/web/$srv/html";           # assume directory

   # prepare HTML output
   my $template = HTML::Template->new(filename => "$srvloc/cluster/$sc
+riptname.htm");
   ...
[download]

the corresponding html would be edited in Dreamweaver (or whatever you like) and look like:

  ...
   <td class="pid">
     <TMPL_IF idproc>
     <a href="/cgi-bin/myprocess.pl/ii/<TMPL_VAR NAME="host">/<TMPL_VA
+R NAME="pid">" 
        title="[pid No.]"><TMPL_VAR NAME="pid">&nbsp;
     </a>
     </TMPL_IF>
   </td>
  ...
[download]

The variables set in the perl program would show up in the html as

 <TMPL_VAR NAME="varname">
[download]

and the perl program would set the variables like:

   ...
   $template->param( 
         host       => $host,  
         cpuid      => $cpuid,
         cpuidcolor => $cpuidtab{$cpuid}
   );
   ...
   ...
   print "Content-type: text/html\n\n", $template->output;
[download]

where he last line would send the html to the browser.

So that's what I'd recommend. HTML::Template is ideal suited for this kind of CGI-script things.

Regards

mwa

One big advantage you get using a templating system is separating the code from the HTML. This allows a programmer to work on the code and a web designer to work on the HTML. If you're working alone this isn't as big of an advantage but I've found it helps me concentrate better on one when I'm not staring at the other. It's a lot easier to understand both the code and the HTML when they're compact and flowing instead of intermixed.

Having just recently gone back and TT-ified a report generator (that in 20/20 hindsight probably should have started with a template :) I'd offer at least this advice:

If you do use here-docs and/or qq{} try and make as much effort as possible not to interleave any computation or manipulation in with the printing. That way in n months when you do break down and bite the bullet (because after the xth request to add just one more thing . . .; oh, and we want a Blackberry friendly version of the same information so you need to make another copy aimed at a 2" wide screeen but the BB browser is dane bramaged enough to not understand sufficient CSS to do it that way) you don't have to spend a bunch of time extracting that logic and moving it elsewhere.

The power of the template language makes for MVC like another poster mentioned, the seperation of content, data, and templates.

My recommendation for a templating system is Template-Toolkit. It's widely in use, has many (useful) features, is extensible and it can be used for all kind of templating problems, not just html templating.

I can't recommend a templating system enough. I wrote dynamic Web sites with HERE docs for a couple of years and then switched to HTML::Template. Keeping the server-side separate from the client-side is huge in my graphic design firm where I have people doing HTML, but don't know a lick of Perl.

The next huge advance for me was switching to CGI::Application, a framework that makes working with dynamic Web sites and templating systems so much easier (lots of great plugins).