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

Motatorious Monks,

On advice from other Monks in another thread, I'm reading all about Template::Toolkit. Very nice so far, but I wanted to check that I'm grasping the concepts and ramificiations.

http://www.devshed.com/c/a/Perl/Building-a-Complete-Website-using-the-Template-Toolkit/3/

This tutorial mentions:

The tpage program is fine for processing single templates, but isn’t really designed to handle the many pages that comprise a typical web site. For this, ttree is much more appropriate. It works by drilling down through a source directory of your choosing, looking for templates to process. The output generated is saved in a corresponding file in a separate destination directory.

But I don't have a million different templates. I'll have one or two templates to fill with hundreds of different contents. What I've got to start with is hundreds of content pages that I want to merge with a layout template to produce finished web pages. The above tutorial makes it sound backwards to me.

Next is how this is run. It speaks opf running tpage or ttree from the command line to generate pages that are stored as static html on the server. The pre-generating static html sounds great. But in this age of do-it-yourself web authors, I can hardly ask office staff who are authoring content to telnet into the server to run this everytime they make a change to their content page. Way too cumbersome.

Is there not some way to do this automatically?

Thanks.




Forget that fear of gravity,
Get a little savagery in your life.
  • Comment on Learning Template::Toolkit - have I understood?

Replies are listed 'Best First'.
Re: Learning Template::Toolkit - have I understood?
by imp (Priest) on Aug 30, 2006 at 12:36 UTC
    The answer to that question really depends on what you are trying to do with Template Toolkit.

    Are you generating static HTML pages, or writing templates that will have content populated by a cgi script?

    tpage is just a simple script for wrapping the perl modules that generate html from a template.
    ttree is similar, but works recursively over directories.

    For generating dynamic content I found this tutorial helpful. I don't have time this morning to read over the devshed one, but it probably covers similar content.

    Update

    After re-reading your post it sounds like other people edit content documents, which you then place within a wrapper template. If this is the case then you should look at the INSERT and INCLUDE directives.

    If you want to generate static pages then one of the variables passed to the template can be the name of another template . The following command would generate the template, defining the 'content_file' variable with the value 'content/foo.html':

    tpage --define content_file=content/foo.html wrapper.html > > static- +foo.html
    And in your template:
    <html> ... [ INSERT $content_file ] ... </html>
Re: Learning Template::Toolkit - have I understood?
by Khen1950fx (Canon) on Aug 30, 2006 at 09:05 UTC
    I've just read "Building a Complete Website using the Template Toolkit". It's incredibly complex and can be very intimidating at first; however, I reread it, and it does seem backwards. But I think that what they said about ttree was right on. To me, it all boils down to the proper use of options. For instance, you have one or two templates---Using the pre_process and post_process options enables you specify one or more templates to be added to the top or bottom of the page templates automatically. Then your contents, stored in a separate html file can be added, copied, or ignored as needed. At least that's how I read it and understood it. And there's hundreds of options. Keep the man pages open for this one.
Re: Learning Template::Toolkit - have I understood?
by punch_card_don (Curate) on Aug 30, 2006 at 13:59 UTC
    1. RE: Dynamic generation - yes, that's certainly one option I'm considering. I like the idea of pre-generation of static html pages for the clarity, the server load. But this requirement for authors to launch a generation routine each time they make a change is a stumbling block. One possible compromise would be a secure author's control panel page with a "Generate!" button that launches a cgi script to do all the work. It's not bad.

    2. RE: ttree recursion vs. content recursion - From the tutorial suggested above, I note: DYNAMIC CONTENT GENERATION VIA CGI SCRIPT

    #!/usr/bin/perl -w use strict; use Template; my $file = 'src/greeting.html'; my $vars = { message => "Hello World\n" }; my $template = Template->new(); $template->process($file, $vars) || die "Template process failed: ", $template->error(), "\n";
    Which I believe implies that although TT has ttree to automatically drill down through a hierarchy to find and process a whack of templates, if I have only one template and a whack of content files, I have to do the recursion work myself. To my mind, this seems a little backwards, since a large template-driven site is rarely going to be the first case, and much more commonly going to be the second case. No?

    So, OK, I make my template with the appropriate INCLUDES, etc. Then I have to write a script that travels my website structure looking for content files (probably designated by an extension), and merging them with the template. To be honest, I could have done that myself with a couple of custom markers in the html files and a little routine to scour the pages for the markers, parse out the tag and shunt to a corresponding insertion routine. But I guess the moduloe has the advantage of lots of other functionality for the future...




    Forget that fear of gravity,
    Get a little savagery in your life.
      One way to deal with re-generation is to use a cron to generate the whole thing (or just changes) every 15 minutes. Then you can tell people their changes will be live in 15 minutes.

      It doesn't like ttree is a good fit for you though. Just write your own script that grabs all the content and calls TT directly. It's not hard. There's no reason to use ttree if it doesn't obviously fit your model.

      I like the idea of pre-generation of static html pages for the clarity, the server load.

      You might consider Template caching (see "Caching and Compiling Options") as a easy solution for that issue.

      To my mind, this seems a little backwards, since a large template-driven site is rarely going to be the first case, and much more commonly going to be the second case. No?

      If you're converting to TT from a HTML-only design, yes, it's backwards. And that's not something TT was designed for; it's mostly built for ground-up design with TT in mind.

      So, first off, you can indicate that TT "scoop up" .html files, or any other content. The INCLUDE_PATH option will contain a list of directories to look in, and you can write a quickie "generator" for it to recurse through your directory structure if you'd like, or manually list the directories; it's your choice. Make a "base" template, use the WRAPPER option, and then the "sub-templates" with the content get slugged in via the [% content %] tag. I strongly recommend skimming the various parts of the Template Manual; there is a LOT of power to the Template Toolkit that's not obvious, and it not "typical usage", as you've surmised.

      Does that help?

      ----Asim, known to some as Woodrow.

Re: Learning Template::Toolkit - have I understood?
by dtr (Scribe) on Aug 30, 2006 at 13:14 UTC

    Have you see the module Apache::Template? This requires a mod_perl enabled apache, but allows you to get apache to process your templates before sending them to the recipient - which will mean that your office staff won't have to telnet into the server :)