NAME

Text::Template - Expand template text with embedded Perl

SYNOPSIS

 use Text::Template;

 $template = new Text::Template (TYPE => FILE,  SOURCE => 'filename.tmpl');
 $template = new Text::Template (TYPE => ARRAY, SOURCE => [ ... ] );
 $template = new Text::Template (TYPE => FILEHANDLE, SOURCE => $fh );
 $template = new Text::Template (TYPE => STRING, SOURCE => '...' );

 $recipient = 'King';
 $text = $template->fill_in();  # Replaces `{$recipient}' with `King'
 print $text;

 $T::recipient = 'Josh';
 $text = $template->fill_in(PACKAGE => T);
 print $text;

 $text = $template->fill_in(BROKEN => \&callback, BROKEN_ARG => [...]);
 $text = $template->fill_in(SAFE => $compartment, ...);

 use Text::Template 'fill_in_string';
 $text = fill_in_string( <<EOM, 'package' => T);
 Dear {$recipient},
 Pay me at once.
        Love, 
         G.V.
 EOM

 use Text::Template ''fill_in_file';
 $text = fill_in_file($filename, ...);

DESCRIPTION

This is a library for generating form letters, building HTML pages, or filling in templates generally. A `template' is a piece of text that has little Perl programs embedded in it here and there. When you `fill in' a template, you evaluate the little programs and replace them with their values.

Here's an example of a template:

        Dear {$title} {$lastname},

        It has come to our attention that you are delinquent in your
        {$monthname[$last_paid_month]} payment.  Please remit
        ${sprintf("%.2f", $amount)} immediately, or your patellae may
        be needlessly endangered.

                        Love,

                        Mark "Vizopteryx" Dominus

The result of filling in this template is a string, which might look something like this:

        Dear Mr. Gates,

        It has come to our attention that you are delinquent in your
        February payment.  Please remit
        $392.12 immediately, or your patellae may
        be needlessly endangered.


                        Love,

                        Mark "Vizopteryx" Dominus

You can store a template in a file outside your program. People can modify the template without modifying the program. You can separate the formatting details from the main code, and put the formatting parts of the program into the template. That prevents code bloat and encourages functional separation.

Template Syntax

When people make a template module like this one, they almost always start by inventing a special syntax for substitutions. For example, they build it so that a string like %%VAR%% is replaced with the value of $VAR. Then they realize the need extra formatting, so they put in some special syntax for formatting. Then they need a loop, so they invent a loop syntax. Pretty soon they have a new little template language.

This approach has two problems: First, their little language is crippled. If you need to do something the author hasn't thought of, you lose. Second: Who wants to learn another language? You already know Perl, so why not use it?

Text::Template templates are programmed in Perl. You embed Perl code in your template, with { at the beginning and } at the end. If you want a variable interpolated, you write it the way you would in Perl. If you need to make a loop, you can use any of the Perl loop constructions. All the Perl built-in functions are available.

Details

Template Parsing

The Text::Template module scans the template source. An open brace { begins a program fragment, which continues until the matching close brace }. When the template is filled in, the program fragments are evaluated, and each one is replaced with the resulting value to yield the text that is returned.

A backslash \ in front of a brace (or another backslash) escapes its special meaning. The result of filling out this template:

        \{ The sum of 1 and 2 is {1+2}  \}

        { The sum of 1 and 2 is 3  }

If you have an unmatched brace, Text::Template will return a failure code and a warning about where the problem is.

Each program fragment should be a sequence of Perl statements, which are evaluated the usual way. The result of the last statement executed will be evaluted in scalar context; the result of this statement is a string, which is interpolated into the template in place of the program fragment itself.

The fragments are evaluated in order, and side effects from earlier fragments will persist into later fragments:

        {$x = @things; ''} The Lord High Chamberlain has gotten {$x}
        things for me this year.  
        { $diff = $x - 17; 
          $more = 'more'
          if ($diff == 0) {
            $diff = 'no';
          } elsif ($diff < 0) {
            $more = 'fewer';
          } 
        } 
        That is {$diff} {$more} than he gave me last year.

The value of $x set in the first line will persist into the next fragment that begins on the third line, and the values of $diff and $more set in the second fragment will persist and be interpolated into the last line. The output will look something like this:

         The Lord High Chamberlain has gotten 42
        things for me this year.  

        That is 35 more than he gave me last year.

That is all the syntax there is.

General Remarks

All Text::Template functions return undef on failure, and set the variable $Text::Template::ERROR to contain an explanation of what went wrong. For example, if you try to create a template from a file that does not exist, $Text::Template::ERROR will contain something like:

        Couldn't open file xyz.tmpl: No such file or directory

`new`

        $template = new Text::Template ( attribute => value, ... );

This creates and returns a new template object. You specify the source of the template with a set of attribute-value pairs in the arguments. It returns undef and sets $Text::Template::ERROR if it can't create the template object.

The TYPE attribute says what kind of thing the source is. Most common is a filename:

        new Text::Template ( TYPE => 'FILE', SOURCE => $filename );

This reads the template from the specified file. The filename is opened with the Perl open command, so it can be a pipe or anything else that makes sense with open.

The TYPE can also be STRING, in which case the SOURCE should be a string:

        new Text::Template ( TYPE => 'STRING', 
                             SOURCE => "This is the actual template!" );

The TYPE can be ARRAY, in which case the source should be a reference to an array of strings. The concatenation of these strings is the template:

        new Text::Template ( TYPE => 'ARRAY', 
                             SOURCE => [ "This is ", "the actual", 
                                         " template!",
                                       ]
                           );

The TYPE can be FILEHANDLE, in which case the source should be an open filehandle (such as you got from the FileHandle or IO::* packages, or a glob, or a reference to a glob). In this case Text::Template will read the text from the filehandle up to end-of-file, and that text is the template.

If you omit the TYPE attribute, it's taken to be FILE. SOURCE is required. If you omit it, the program will abort.

The words TYPE and SOURCE can be spelled any of the following ways:

        TYPE    SOURCE
        Type    Source
        type    source
        -TYPE   -SOURCE
        -Type   -Source
        -type   -source

Pick a style you like and stick with it.

`compile`

        $template->compile()

Loads all the template text from the template's source, parses and compiles it. If successful, returns true; otherwise returns false and sets $Text::Template::ERROR. If the template is already compiled, it returns true and does nothing.

You don't usually need to invoke this function, because fill_in (see below) compiles the template if it isn't compiled already.

`fill_in`

        $template->fill_in(OPTIONS);

Fills in a template. Returns the resulting text if successful. Otherwise, returns undef and sets $Text::Template::ERROR.

The OPTIONS are a hash, or a list of key-value pairs. You can write the key names in any of the six usual styles as above; this means that where this manual says PACKAGE you can actually use any of

        PACKAGE Package package -PACKAGE -Package -package

Pick a style you like and stick with it. The all-lowercase versions may yield spurious warnings about

        Ambiguous use of package => resolved to "package"

so you might like to avoid them and use the capitalized versions.

At present, there are four legal options: PACKAGE, BROKEN, BROKEN_ARG, and SAFE.

PACKAGE

PACKAGE specifies the name of a package in which the program fragments should be evaluated. The default is to use the package from which fill_in was called. For example, consider this template:

        The value of the variable x is {$x}.

If you use $template->fill_in(PACKAGE => 'R') , then the $x in the template is actually replaced with the value of $R::x. If you omit the PACKAGE option, $x will be replaced with the value of the $x variable in the package that actually called fill_in.

You should almost always use PACKAGE. If you don't, and your template makes changes to variables, those changes will be propagated back into the main program. Evaluating the template in a private package helps prevent this. The template can still modify variables in your program if it wants to, but it will have to do so explicitly. See the section at the end on `Security'.

Here's an example of using PACKAGE:

        Your Royal Highness,

        Enclosed please find a list of things I have gotten
        for you since 1907:

        { $list = '';
          foreach $item (@items) {
            $list .= " o \u$item\n";
          }
          $list;
        }

        Signed,
        Lord High Chamberlain

We want to pass in an array which will be assigned to the array @items. Here's how to do that:

        @items = ('ivory', 'apes', 'peacocks', );
        $template->fill_in();

This is not very safe. The reason this isn't as safe is that if you had any variables named $list or $item in scope in your program at the point you called fill_in, their values would be clobbered by the act of filling out the template. The problem is the same as if you had written a subroutine that used those variables in the same waythat the template does.

One solution to this is to make the $item and $list variables private to the template by declaring them with my. If the template does this, you are safe.

But if you use the PACKAGE option, you will probably be safe even if the template does not declare its variables with my:

        @Q::items = ('ivory', 'apes', 'peacocks', );
        $template->fill_in(PACKAGE => 'Q');

In this case the template will clobber the variables $Q::item and $Q::list, which are not related to the ones your program was using.

Templates cannot affect variables in the main program that are declared with my, unless you give the template references to those variables.

HASH

You may not want to put the template variables into a package. Packages can be hard to manage: You can't copy them, for example. HASH provides an alternative.

The value for HASH should be a reference to a hash that maps variable names to values. For example,

        $template->fill_in(HASH => { recipient => "The King",
                                     items => ['gold', 'frankincense', 'myrrh']
                                   });

will fill out the template and use "The King" as the value of $recipient and the list of items as the value of @items.

The full details of how it works are a little involved, so you might want to skip to the next section.

Suppose the key in the hash is key and the value is value.

If the value is undef, then any variables named $key, @key, %KEY, etc., are undefined.
If the value is a string or a number, then $key is set to that value in the template.
If the value is a reference to an array, then @key is set to that array. If the value is a reference to a hash, then %key is set to that hash. Similarly if value is any other kind of reference. This means that
```
        var => "foo"
```
and
```
        var => \"foo"
```
have almost exactly the same effect. (The difference is that in the former case, the value is copied, and in the latter case it is aliased.)

Normally, the way this works is by allocating a private package, loading all the variables into the package, and then filling out the template as if you had specified that package. A new package is allocated each time. However, if you also use the PACKAGE option, Text::Template loads the variables into the package you specified, and they stay there after the call returns. Subsequent calls to fill_in that use the same package will pick up the values you loaded in.

If the argument of HASH is a reference to an array instead of a reference to a hash, then the array should contain a list of hashes whose contents are loaded into the template package one after the other. You can use this feature if you want to combine several sets of variables. For example, one set of variables might be the defaults for a fill-in form, and the second set might be the user inputs, which override the defaults when they are present:

        $template->fill_in(HASH => [\%defaults, \%user_input]);

You can also use this to set two variables with the same name:

        $template->fill_in(HASH => [{ v => "The King" },
                                    { v => [1,2,3] },
                                   ]
                          );

This sets $v to "The King" and @v to (1,2,3).

BROKEN

If any of the program fragments fails to compile or aborts for any reason, Text::Template will call the BROKEN function that you supply with the BROKEN attribute. The function will tell Text::Template what to do next. The value for this attribute is a reference to your BROKEN function.

If the BROKEN function returns undef, Text::Template will immediately abort processing the template and return the text that it has accumulated so far. If your function does this, it should set a flag that you can examine after fill_in returns so that you can tell whether there was a premature return or not.

If the BROKEN function returns any other value, that value will be interpolated into the template as if that value had been the return value of the program fragment to begin with.

If you don't specify a BROKEN function, Text::Template supplies a default one that returns something like

        Program fragment at line 17 delivered error ``Illegal
        division by 0''

Since this is interpolated into the template at the place the error occurred, a template like this one:

        (3+4)*5 = { 3+4)*5 }

yields this result:

        (3+4)*5 = Program fragment at line 1 delivered error
        ``syntax error''

If you specify a value for the BROKEN attribute, it should be a reference to a function that fill_in can call instead of the default function.

fill_in will pass an associative array to the broken function. The associative array will have at least these four members:

text: The source code of the program fragment that failed
error: The text of the error message ($@) generated by eval
lineno: The line number of the template data at which the program fragment began

There may also be an arg member. See BROKEN_ARG, below

BROKEN_ARG

If you supply the BROKEN_ARG option to fill_in, the value of the option is passed to the BROKEN function whenever it is called. The default BROKEN function ignores the BROKEN_ARG, but you can write a custom BROKEN function that uses the BROKEN_ARG to get more information about what went wrong.

The BROKEN function could also use the BROKEN_ARG as a reference to store an error message or some other information that it wants to communicate back to the caller. For example:

        $error = '';

        sub my_broken { 
           my %args = @_;
           my $err_ref = $args{arg};
           ...
           $$err_ref = "Some error message";
           return undef;
        }

        $template->fill_in(BROKEN => \&my_broken,
                           BROKEN_ARG => \$error,
                          );

        if ($error) {
          die "It didn't work: $error";
        }

If one of the program fragments in the template fails, it will call the BROKEN function, my_broken, and pass it the BROKEN_ARG, which is a reference to $error. my_broken can store an error message into $error this way. Then the function that called fill_in can see if my_broken has left an error message for ity to find, and proceed accordingly.

SAFE

If you give fill_in a SAFE option, its value should be a safe compartment object from the Safe package. All evaluation of program fragments will be performed in this compartment. See Safe for full details.

Convenience Functions

`fill_this_in`

The basic way to fill in a template is to create a template object and then call fill_in on it. This is useful if you want to fill in the same template more than once.

In some programs, this can be cumbersome. fill_this_in accepts a string, which contains the template, and a list of options, which are passed to fill_in as above. It constructs the template object for you, fills it in as specified, and returns the results. It returns undef and sets $Text::Template::ERROR if it couldn't generate any results.

An example:

        $Q::name = 'Donald';
        $Q::amount = 141.61;
        $Q::part = 'hyoid bone';

        $text = Text::Template->fill_this_in( <<EOM, PACKAGE => Q);
        Dear {\$name},
        You owe me {sprintf('%.2f', \$amount)}.  
        Pay or I will break your {\$part}.
                Love,
                Grand Vizopteryx of Irkutsk.
        EOM

Notice how we included the template in-line in the program by using a `here document' with the << notation.

fill_this_in is probably obsolete. It is only here for backwards compatibility. You should use fill_in_string instead. It is described in the next section.

`fill_in_string`

It is stupid that fill_this_in is a class method. It should have been just an imported function, so that you could omit the Text::Template-> in the example above. But I made the mistake four years ago and it is too late to change it.

fill_in_string is exactly like fill_this_in except that it is not a method and you can omit the Text::Template-> and just say

        print fill_in_string(<<EOM, ...);
        Dear {$name},
          ...
        EOM

To us fill_in_string, you need to say

        use Text::Template 'fill_in_string';

at the top of your program. You should probably use fill_in_string instead of fill_this_in.

`fill_in_file`

If you import fill_in_file, you can say

        $text = fill_in_file(filename, ...);

The ... are passed to fill_in as above. The filename is the name of the file that contains the template you want to fill in. It returns the result text. or undef, as usual.

If you are going to fill in the same file more than once in the same program you should use the longer new / fill_in sequence instead. It will be a lot faster because it only has to read and parse the file once.

Including files into templates

People always ask for this. ``Why don't you have an include function?'' they want to know. The short answer is this is Perl, and Perl already has an include function. If you want it, you can just put

        {qx{cat filename}}

into your template. Voila.

If you don't want to use cat, you can write a little four-line function that opens a file and dumps out its contents, and call it from the template. I wrote one for you. In the template, you can say

        {Text::Template::_load_text(filename)}

If that is too verbose, here is a trick. Suppose the template package that you are going to be mentioning in the fill_in call is package Q. Then in the main program, write

        *Q::include = \&Text::Template::_load_text;

This imports the _load_text function into package Q with the name include. From then on, any template that you fill in with package Q can say

        {include(filename)}

to insert the text from the named file at that point.

Suppose you don't want to insert a plain text file, but rather you want to include one template within another? Just use fill_in_file in the template itself:

        {Text::Template::fill_in_file(filename)}

You can do the same importing trick if this is too much to type.

Miscellaneous

`my` variables

People are frequently surprised when this doesn't work:

        my $recipient = 'The King';
        my $text = fill_in_file('formletter.tmpl');

The text The King doesn't get into the form letter. Why not? Because $recipient is a my variable, and the whole point of my variables is that they're private and inaccessible except in the scope in which they're declared. The template is not part of that scope, so the template can't see them.

If that's not what you want, don't use my. Put the variables into package variables in some other package, and use the PACKAGE option to fill_in, or pass the names and values in a hash with the HASH option.

Security Matters

All variables are evaluated in the package you specify with the PACKAGE option of fill_in. if you use this option, and if your templates don't do anything egregiously stupid, you won't have to worry that evaluation of the little programs will creep out into the rest of your program and wreck something.

Nevertheless, there's really no way (except with Safe) to protect against a template that says

        { $Important::Secret::Security::Enable = 0; 
          # Disable security checks in this program 
        }

        { $/ = "hoho";   # Sabotage future uses of <FH>.
          # $/ is always a global variable
        }

or even

        { system("rm -rf /") }

so don't go filling in templates unless you're sure you know what's in them. If you're worried, use the SAFE option.

As a final warning, program fragments run a small risk of accidentally clobbering local variables in the fill_in function itself. These variables all have names that begin with $fi_, so if you stay away from those names you'll be safe. (Of course, if you're a real wizard you can tamper with them deliberately for exciting effects.)

JavaScript

Jennifer D. St Clair asks:

        > Most of my pages contain JavaScript and Stylesheets.
        > How do I change the template identifier?

Jennifer is worried about the braces in the JavaScript being taken as the delimiters of the Perl program fragments. Of course, disaster will ensure when perl tries to evaluate these as if they were Perl programs.

I didn't provide a facility for changing the braces to something else, because it complicates the parsing, and in my experience it isn't necessary. There are two easy solutions:

1. You can put \ in front of {, }, or \ to remove its special meaning. So, for example, instead of

            if (br== "n3") { 
                // etc.
            }

you can put

            if (br== "n3") \{ 
                // etc.
            \}

and it'll come out of the template engine the way you want.

But here is another method that is probably better. To see how it works, first consider what happens if you put this into a template:

            { 'foo' }

Since it's in braces, it gets evaluated, and obviously, this is going to turn into

foo

So now here's the trick: In Perl, q{...} is the same as '...'. So if we wrote

            {q{foo}}

it would turn into

foo

So for your JavaScdript, just write

            {q{
              if (br== "n3") { 
                  // etc.
              }
            }

and it'll come out as

              if (br== "n3") { 
                  // etc.
              }

which is what you want.

This trick is so easy that I thought didn't need to put in the feature that lets you change the bracket characters to something else.

Compatibility

Every effort has been made to make this module compatible with older versions. The single exception is the output format of the default BROKEN subroutine; I decided that the olkd format was too verbose. If this bothers you, it's easy to supply a custom subroutine that yields the old behavior.

This version passes the test suite from the old version. The old test suite is too small, but it's a little reassuring.

A short note about `$Text::Template::ERROR`

In the past some people have fretted about `violating the package boundary' by examining a variable inside the Text::Template package. Don't feel this way. $Text::Template::ERROR is part of the published, official interface to this package. It is perfectly OK to inspect this variable. The interface is not going to change.

If it really, really bothers you, you can import a function called TTerror that returns the current value of the $ERROR variable. So you can say:

        use Text::Template 'TTerror';

        my $template = new Text::Template (SOURCE => $filename);
        unless ($template) {
          my $err = TTerror;
          die "Couldn't make template: $err; aborting";
        }

I don't see what benefit this has over just doing this:

        use Text::Template;

        my $template = new Text::Template (SOURCE => $filename)
          or die "Couldn't make template: $Text::Template::ERROR; aborting";

But if it makes you happy to do it that way, go ahead.

Sticky Widgets in Template Files

The CGI module provides functions for `sticky widgets', which are form input controls that retain their values from one page to the next. Sometimes people want to know how to include these widgets into their template output.

It's totally straightforward. Just call the CGI functions from inside the template:

        { $q->checkbox_group(NAME => 'toppings',
                             LINEBREAK => true,
                             COLUMNS => 3,
                             VALUES => \@toppings],
                            );
        }

Author

Mark-Jason Dominus, Plover Systems

mjd-perl-template@pobox.com

You can join a very low-volume (<10 messages per year) mailing list for announcements about this package. Send an empty note to mjd-perl-template-request@plover.com to join.

For updates, visit http://www.plover.com/~mjd/perl/Template/.

Support?

This software is version 1.0. It is a complete rewrite of an older package, and may have bugs. It is inadequately tested. Suggestions and bug reports are always welcome. Send them to mjd-perl-template@plover.com.

Thanks

Many thanks to the following people for offering support, encouragement, advice, and all the other good stuff. Especially to Jonathan Roy for telling me how to do the Safe support (I spent two years worrying about it, and then Jonathan pointed out that it was trivial.)

Klaus Arnhold / Mike Brodhead / Tom Brown / Tim Bunce / Juan E. Camacho / Joseph Cheek / San Deng / Bob Dougherty / Dan Franklin / Todd A. Green / Michelangelo Grigni / Tom Henry / Matt X. Hunter / Robert M. Ioffe / Daniel LaLiberte / Reuven M. Lerner / Joel Meulenberg / Jason Moore / Bek Oberin / Ron Pero / Hans Persson / Jonathan Roy / Jennifer D. St Clair / Uwe Schneider / Randal L. Schwartz / Michael G Schwern / Brian C. Shensky / Niklas Skoglund / Tom Snee / Hans Stoop / Michael J. Suzio / Dennis Taylor / James H. Thompson / Shad Todd / Andy Wardley / Matt Womer / Andrew G Wood / Michaely Yeung

Bugs and Caveats

my variables in fill_in are still susceptible to being clobbered by template evaluation. They all begin with fi_, so avoid those names in your templates.

Maybe there should be a utility method for emptying out a package?Or for pre-loading a package from a hash?

Maybe there should be a control item for doing #if. Perl's `if' is sufficient, but a little cumbersome to handle the quoting. Ranjit and I brainstormed a wonderful general solution to this which may be forthcoming.

The line number information will be wrong if the template's lines are not terminated by "\n". Someone should let me know if this is a problem.

There are not enough tests in the test suite.

To install Text::Template, copy and paste the appropriate command in to your terminal.

cpanm

cpanm Text::Template

CPAN shell

perl -MCPAN -e shell
install Text::Template

For more information on module installation, please visit the detailed CPAN module installation guide.

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

	Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)