i prefer to just have a 'templates' subdirectory in each application's directory that contains the templates and use CVS to let the designers tweak them. then i'm the only one who can update the production site and i only do so after testing on a staging site. that will prevent the designers from ever really screwing up something production. when you first try to teach your designers how to use CVS, they may kick and scream a bit and don't be alarmed if blood streams out of their eyes and ears, but eventually they'll usually manage to understand enough to do a basic 'cvs commit' and 'cvs update'.

however you do it, i'd also recommend having a function somewhere in a common library that lets you just call it like my $template = template("foo_template.tmpl") and returns the loaded HTML::Template object with all the options you want and with the template file from whatever template directory you've settled on. this will prevent you from accidently forgetting to add 'die_on_bad_params' or 'loop_context_vars' every time (if you want them) and it makes it easier if you change your mind on where your templates live later on.

This question has come up on the cgi-app list a few times.

CGI::Application also has a wiki. This page has some answers to this very question.

HTH

(copied from CGI::Session's Cookbook Tutorial.pm)

...associate the $session object with that of HTML::Template:

    $template = new HTML::Template(filename=>"some.tmpl", 
associate=>$session );
[download]

Now in your ``some.tmpl'' template you can access the above history like so:

    <!-- left menu starts -->
    <table width="170">
        <tr>
            <th> last visited pages </th>
        </tr>
        <TMPL_LOOP NAME=HISTORY>
        <tr>
            <td>
            <a href="<TMPL_VAR NAME=LINK>"> <TMPL_VAR NAME=TITLE> </a>
            </td>
        </tr>
        </TMPL_LOOP>
    </table>
    <!-- left menu ends -->
[download]

Please, observe that the same hash ref. ($session object) is applied directly in the HT since it's structure is the same. So you could mention the same hash keys in the template (see the LOOP NAME)

I have also found out that CGI::Application has some special functions reserved for HT in this same fashion (and you don't need to declare HT in it).

Refering to the place of the templates, I have discovered that CGI::Framework (similar to CA) needs to name the template's extensions as .html. In this case, you wouldn't be able to mix templates with html files in the same directory. So, having them outside the reach of your server is clever: because you don't have to change the servers' extensions to prevent opening a template instead of a normal html file.

With all these 'canned' programming experience of the mentioned modules, it is easy to become a famous webmaster in a few months!

I plan to review the links ya'll have supplied, and see where I can make improvements.