tiklooT::etalpmeT

Let’s say, purely as a hypothetical of course, that you’re using perl’s Template::Toolkit to control an application’s front end.

Reasonable enough. Let’s further posit that at a certain point in the application you realize that, while you of course know how to send variables and data from your perl scripts into your templates, you have no idea how to do the reverse: give your perl script access to the variables you defined inside the template.

Let’s assume that after quite a bit of googling you’re starting to have the sinking feeling that you must be either Doing It Wrong or Missing Something Really Obvious, because there doesn’t seem to be any discussion in the docs or on the net about what seems like it would be a really basic need.

But then let’s assume you somehow stumbled across this page. Now you no longer have the sinking feeling that you’re Doing It Wrong. Instead you have the comfortable feeling that While You May Be Doing It Wrong, At Least One Person Out There Is Doing It Wrong The Same Way.

#!/usr/bin/perl
use Template;
use Template::Context;
my $context = Template::Context->new();
my $template = Template->new({ CONTEXT => $context });
$template->process("foo.tmpl");
my $global = $context->{STASH}->get("global");

In other words, create a template object with a local variable for its context; process the template containing the variables you want to read; and finally use Stash->get() to read whichever variables you’re after.

Why would you do this? In my case, I wanted to have a single config file for an application that would be used in lots of different contexts — so I wanted to make a single config file containing all the variables that would differ between the various installations. These variables needed to be accessible in both the templates themselves and in the perl code which uses them.

The Toolkit documentation makes it very clear how to define variables inside the templates, or to define them inside perl and then pass them on to the template. What’s less clear is how to make them go the other way, to define the variables inside the template but read them from inside perl.

Obviously I could’ve (and possibly should’ve) just defined them inside the perl script and passed them to the templates as needed. But then I’d be modifying the scripts for every installation, which seemed to defeat the whole idea of using a template system.

I’m sure this is a no-brainer for regular users of Template Toolkit, but it took me long enough to work out that I figured it might be useful for somebody else. If it turns out I’ve managed to find a really convoluted or inefficient way to do something that could be done much more simply, then let me know.

3 Comments:

Most perl-based apps I use with configurations simply have their configuration be essentially another module that the main script imports. The downside is that the configuration is in perl, but the upside is that it’s really easy to load.

If you trust your users (or yourself) to configure it appropriately and not break syntax, then I’d recommend this way. Not sure how sensitive the Template system is to syntax errors though, so that might be the key.

Amavis (a mail scanning tool) is a prime example of this, btw.

Yeah, in this particular case the configuration was stuff that template authors needed to be able to control, and I was trying to draw a hard line between the perl code (which I didn’t want them to touch) and the templates (which I didn’t want to have to bother with.) Probably not the best approach, but it worked well enough (it’s still driving this very website, for a start. :)

There was also the multiple-installation issue to deal with (this same codebase is driving a few other sites, inkberry for example); I did wind up including a .pm for some of the back-end configuration too.

(There are still some bugs which I’ll probably never get around to fixing, such as figuring out why this three-year-old post showed up in the RSS feed yesterday…)

haha! I didn’t even notice the post date ;) Well I’m glad you figured it out :) All my multiple installations of a single codebase are managed by me, so I get to cheat on writing configs. Good thing to think about.