Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Organizational strategies when using HTML::Template

by Hagbone (Monk)
on Jan 10, 2004 at 21:17 UTC ( #320382=perlquestion: print w/replies, xml ) Need Help??

Hagbone has asked for the wisdom of the Perl Monks concerning the following question:


Was hoping for some input, opinions, etc., regarding organizational strategies used by others using HTML::Template.

I'm just getting my feet wet with the Module, and am finding it *very, very* cool.

Since I'm just starting to incorporate it into my site management plan (I have to retrofit it gradually into a relatively complex site), I'm trying to establish some ground rules in the interests in getting off on the right foot - and maybe equally important, not painting myself into a corner due to inital organizational mistakes.

One concept I'm considering is placing all the HTML::Template related template files in an entirely different area then the main site that they will service ... the template files would be housed on the same box, but in a diiferent user (in the ftp log in sense) area. My rationale is that this would allow a HTML designer full ftp access to the templates, but without handing over the "keys" to the real site, maybe avoiding a potential (likely unintentional) hosing of the real site.

As I said, I'm a full blown rookie when it comes to HTML::Template, so maybe my approach is crazy ... hence the question.

FWIW, I have (just) signed on to the HTML::Template mailing list in the hopes of learning more.

  • Comment on Organizational strategies when using HTML::Template

Replies are listed 'Best First'.
Re: Organizational strategies when using HTML::Template
by thraxil (Prior) on Jan 10, 2004 at 22:08 UTC

    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.

Re: Organizational strategies when using HTML::Template
by LTjake (Prior) on Jan 12, 2004 at 02:08 UTC

    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.


    "Go up to the next female stranger you see and tell her that her "body is a wonderland."
    My hypothesis is that she’ll be too busy laughing at you to even bother slapping you.
    " (src)

Re: Organizational strategies when using HTML::Template
by bradcathey (Prior) on Jan 11, 2004 at 20:47 UTC
    Hagbone, great question and welcome to HTML::Template. In answer to your question, in our shop we keep all *.tmpl files in a directory off the root directory. We only have two designers and they know what they are doing, so protecting the files from harm is not a huge concern. I still maintain the Perl in the cgi-bin.

    My biggest learning mistake with H::T was not knowing and taking advantage of all its features. Be sure to read the CPAN docs thoroughly, and memorize jeffa's terrific tutorial, especially the "Bag of Tricks" section (also see Ovid's and gav^'s) The key to planning your workflow is knowing all that H::T can do.

    I also replied to a larger thread, all of which you should take a look at (kiat had a lot of posts on this topic back in December, so check his posts).

    In any case, your designer's will love you.

    "A little yeast leavens the whole dough."
      (copied from CGI::Session's Cookbook

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

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

      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 -->

      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!

Re: Organizational strategies when using HTML::Template
by Hagbone (Monk) on Jan 13, 2004 at 00:03 UTC
    Thanks to all for your responses .... I've been working at some "mock up" scenarios which only serve to convince me that HTML::Template is a powerful approach.

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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://320382]
Approved by Thelonius
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2022-07-06 07:16 GMT
Find Nodes?
    Voting Booth?

    No recent polls found