I'm currently in the process of removing all of my HTML from my CGI scripts and replacing it with the Template Toolkit (see www.tt2.org). This means that all of my CGI scripts will look like this:

use strict;
use CGI qw/param header/;
use Template;

my %data;

# Do lots of interesting stuff grabbing the parameters
# and ending up with the data that I need displayed on the
# page in the %data hash

my $tt = Template->new;

print header;

$tt->process('template.tt', \%data)
  || die $tt->error;
[download]

Obvious advantages that I can see:

• Presentation logic all stored in separate template files which can be worked on by designers if required.
• Consistant look and feel to all pages using header and footer templates.
• Static pages can be generated using the ttree program and share the same look and feel as dynamic pages.
• TT2 also works well with mod_perl and comes with an Apache::Template module which can be installed as a mod_perl handler.

Update: The tt2.org url is working again now.

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

I agree with Dave, although I'm not sure that link points to Template Toolkit, looks like freestyle kite flying to me. Then again, I'm sure there is a relationship.

Here is a node about Template vs. HTML::Mason with several links.

I can't think of a reason not to use Template Toolkit, except that it's a whole 'nother protocol to learn. It embeds Perlish stuff inside a skeleton HTML file. I'd be more inclined to want to keep it the other way around. If you have lots of short bits you're gluing together and these bits are relatively stable, you might just build a %bits hash-- with each element being a key name and the value being the bit of text you want to inject. Then you can either assign that value using a CGI method, like print p( $bits{'this_key'} ); This keeps all the bits in a centrally maintainable place which is clear about what they do, and makes the code easier to streamline.

just my two cents, your mileage may vary.

Here's the problem I have with the templating systems. They're fine if you want to remove simple HTML from simple perl, but if you have a very complex HTML display (ie. things get printed several different ways depending on the data you have or don't have) or you have a lot of data, you end up with either a lot of data being stored in memory before it's sent off to the template or you end up with really complicated templates that are no easier to manage than their perl counterparts, and are even more confusing to the graphical designers who work on them.

Let's take, for example, a database pull that prints out entries grouped by day. Let's say we do this for a month, and there's a fairly good number of entries. If you're using DBI, all you have to do is just loop over your rows, printing out the data and, if you've come upon a new day, possibly a date header. However, with templates, you can't do this. You have to read all the data in, process it into its day and entry groups, and then pass it off to the template.

What would make life a whole lot easier is if I could move all my HTML strings out into one file where the strings are named or identified somehow, then print those named (and processed, if they contain variable subs) strings. Then I remove the HTML from my script without losing any of the very clean, efficient functionality of my processing.

Does anyone know of any modules that do that? It's not really a 'template', so to speak, but a connection of named lines.

Actually, your database example wouldn't be a problem with the Template Toolkit. The TT comes with a number of 'plugins' that make interacting with various Perl features much easier. One of these is the DBI plugin.

What you would do is pass into the template, either the SQL to be executed or (more likely) some data to be used in the where clause of your SQL. The DBI plugin will connect to the database, execute the SQL and process the rows one at a time. At no time do you need to have all of the data in memory at once.

--
<http://www.dave.org.uk>

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

Is that the same package that Ovid was talking about yesterday? If so, I think the URL is www.template-toolkit.org. www.tt2.org took me to a kite flying club!

But this package looks good and I'm going to give it a spin.

Update: In the last 5 minutes, I have watched the above link be transformed into "Freestyle: International FreeStyle Kite Flying"
Does anyone know what is going on?

Update 2: I think that Dave is finding out what happened to those sites. But in the meantime, you can access this stuff here.

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

• output not HTML string but the DOM structure in the form of LOL (list of lists). It is serialized in HTML at the top level only.
• use subs instead of scripts. There must be only one script on your site: http sever itself.

A design like this seems to be very flexible and clean.

And yes, I know that the serialization procedure is slow -- now I rewrite it with XS.

Thank you for your comments.

If you're doing the CGI.pm thing.. or using the 'cgi-lib.pl' library (old.. but nice) then subs are the way to go. The biggest single advantage is that maintaining the code is easier. You change one sub to reflect the change across the entire HTML output.

Not sure where I read it, but someone said that if you're going to repeat a line of once even once you should put it into a sub (or function.. or whatever). It makes sense I suppose.

Another alternative would be to put the HTML into strings and print them, but thats almost the same thing.

Chris

$live{$free}||die