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.