• Read some articles about using the model-view-controller pattern with Perl. You can find some on here, and there are some on perl.com, including one that I wrote.
• Imagine that your code has to produce a data structure with zero HTML in it so that it can be used on a dozen different sites with different layouts, including one that uses PDF and one that is plain text e-mail.
• In yur example, I think you'll have a list of countries each of which contains a list of regions, each of which contains a list of wines. Each country, region, and wine will end up being a hash. Those hashes could potentially be represented as objects, and you could make Class::DBI classes for them, although in your example you have used a single large query instead of traversing object relationships to get the data.
• Figure out how to make your code produce that data structure instead of producing HTML.
• Write a template that takes that data structure and produces the HTML you want.
• You want the template to be as simple and as dumb as possible.

I hope that gets you started. If you come to a New York Perl Mongers meeting I can show you how to do it in detail.

Thanks to all who replied; I've been considering everyone's comments and it's all been helpful. Which isn't to say that I now know exactly what I'm doing....

For now I followed mostly Perrin's advice, and rewrote the included code to instead generate a complex data structure that I passed to a Template Toolkit template. I kept all the summary calculations in the Perl, so the only programming-ish things in the template were FOREACH loops and a few conditionals to handle things like the alternate-colored lines and such.

It works perfectly, i.e. exactly the same as it was before but more modifiable. I must say that I still feel a little uncomfortable with it--the programming in the template, while hardly complex, is still programming, and it's distracting to have a different way of handling looping, comparisons, and data structures. But I'm learning, and TT has so much neat stuff that I concede it's probably worthwhile to know more about it in the long run.

Thanks again for the ideas. Next stop, on to Class::DBI!

You are facing the dilemna which faces every Perl coder who has also to do CGI type scripts. Until recently I generated a lot of my HTML using CGI.pm. But, as you have found, it becomes unwieldy and means that every time you want to change a design element you need to dig into the Perl. So, time for templating.

My feeling is that the design problem should be handled in the design phase and that presentation, should as far as possible, be delegated to the template.

This means that you can then effectively use CSS (Get 'Cascading Style Sheets - The Definitive Guide' by Eric Meyer from O'Reilly and 'Eric Meyer on CSS' by Eric Meyer from New Riders, they are an excellent introduction and reference). By doing this you can almost totally divorce the presentation design from the Perl coding. In my own case, I present a lot of dynamically generated forms that write back to databases. They are all perform the same function but I now have just one Perl script that takes a page template that also loads a form template. I now use one form template which has its presentation controlled by a style-sheet with as many as 30-50 different 'content wrappers' or page templates in any given week. These forms at times handle as many as 50,000 completed forms per week.

To me HTML::Mason is not a templating system, it is a code embedding system which tends to make a Perl programmer feel a lot more like a PHP programmer. I write in Perl becuase I want to write in Perl, not PHP! Mind you, there is nothing wrong with PHP, but why use a silly little band-aid when you can do it properly with duct-tape :)

Using Class::DBI and some of the other DBIx series modules can take a lot of heay out of the whole process. CGI.pm is still very useful glue, CGI::Session gets a good rating in this office also.

I spent a lot of time reading the various documents, there are some useful things on this site in particular and also at least one good paper on the mod_perl site about choosing a templating system. Then I started coding, like you my work is getting stuff into and out of databases using Perl, DBI, MySQL and either HTML or in my case a lot of Tk. Test code some applications in each of the different systems, thats the best way to learn!

But I have achieved almost total separation of presentation and data-processing by using HTML::Template, DBI::Class, CGI.pm and CGI::Session.

Of course, as always, YMMV!

jdtoronto

I use HTML::Template because its simple and fast and easy for designers to understand. I think the key about doing templates is rather than think of them as code that controls your formatting, think of them as a formatted page where you can control the content.

To help you along here's a simple example that could be used for your wine website

my @rows = (); # H::T can create a looping structure out of
               # an array of hashes
               # the keys for each hash are the variable
               # names for each row of the loop

# add database stuff here
while(my $ref = $sth->fetchrow_hashref()) {
     # you can mangle whats in ref, I often
     # just push the ref onto the array and try to
     # put my already mangled stuff in the database
     # This only works though if the variable names in
     # the template are the same as your DB column names
     push(@rows,$ref);
}

my $template = HTML::Template->new(filename=>'/path/to/some.tmpl');
# H::T expects a reference to the array
$template->param(wines=>\@rows);

# print your header (CGI or CGI::Simple is still useful for this)
print $cgi->header();

# and then your H::T output
print $template->output();
[download]

Then in your template file, assuming you have wine_name, bottles and country ... it might look something like this:

<table cellspacing="3" cellpadding="3" border="1">
<tr>
    <td><b>Wine</b></td>
    <td><b>Country</b></td>
    <td><b>Bottles</b></td>
</tr>
<tmpl_loop name=wines>
  <tr>
    <td><tmpl_var name=wine_name></td>
    <td><tmpl_var name=country></td>
    <td><tmpl_var name=bottles></td>
  </tr>
</tmpl_loop>
</table>
[download]

Your Perl code will add a new row for each element in your @rows array with each of the variable names as <td> areas. There's tons of other stuff useful for doing things like changing the background color for every other row, etc. Have a look at the loop_context_vars option in the H::T docs for that.

I hope that gives you an idea of how to do it.

my $bgcolor = "#d7d7d7";
for(@{$item_ref}) {
  $bgcolor = ($bgcolor eq "#d7d7d7") ? "#f7f7f7" : "#d7d7d7";
  push @{$nodes}, {
            title  => $q->escapeHTML($_->{'title'}),
            text   => $_->{'text'},
            inid   => $_->{'inid'},
            timestamp => localtime( epochtime($_->{'timestamp'}) ),
            bgcolor   => $bgcolor,
      };
}
[download]

    <table border="1" cellpadding="2" cellspacing="0">
<!-- snip -->
  <tmpl_loop nodes>      
      <tr bgcolor="<tmpl_var bgcolor>">
        <td align="right"><tmpl_var title></td>
    <td rowspan="2"><tmpl_if inid><a href=?idisplay&img=<tmpl_var inid
+> target=_blank><img src=?getimage&img=<tmpl_var inid>&thumb border=0
+></a><tmpl_else>&nbsp;</tmpl_if></td>
      </tr><tr bgcolor="<tmpl_var bgcolor>">
        <td colspan="3">Last modified <tmpl_var timestamp> by <tmpl_va
+r user></td>
      </tr><tr bgcolor="<tmpl_var bgcolor>">
    <td colspan="4"><tmpl_var text></td>
      </tr>
  </tmpl_loop>
    </table>
[download]

<tr bgcolor="<tmpl_if switch_colour>#d7d7d7<tmpl_else>#f7f7f7</tmpl_if
+>">
or
<tr id="<tmpl_if switch_colour>every<tmpl_else>other</tmpl_if>">
[download]

The breakpoint for me has been the number of data consumers whom I am required to support with my perl code. Generally, I write a chunk of code to gather data which helps me do my job. Later, my PHB notices that I have this information and asks me to cook it to produce a report which he can use for politics (budget/staffing/what-have-you). Then his peers/bosses ask for further enhancements for their own political maneuverings and you end up being asked for calculations which make no sense from people you don't even know.

The break point for me has depended upon the uncontrolled data consumers. When I have a single data consumer, templates are overkill. When I have a handfull of relatively similar consumers, HTML::Template does the job just fine. If the community grows too large or too unwieldy, I prefer to dump the data into a platform neutral format (usually with XML::Writer) and make them pony up the resources for formatting (XSLT).

Then you crush them later with the raw data. ;-)