Text::Template - Expand template text with embedded Perl

This file documents CWText::Template version 1.44

 use Text::Template;

 $template = Text::Template->new(TYPE => 'FILE',  SOURCE => 'filename.tmpl');
 $template = Text::Template->new(TYPE => 'ARRAY', SOURCE => [ ... ] );
 $template = Text::Template->new(TYPE => 'FILEHANDLE', SOURCE => $fh );
 $template = Text::Template->new(TYPE => 'STRING', SOURCE => '...' );
 $template = Text::Template->new(PREPEND => q{use strict;}, ...);

 # Use a different template file syntax:
 $template = Text::Template->new(DELIMITERS => [$open, $close], ...);

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

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

 # Pass many variables explicitly
 $hash = { recipient => 'Abed-Nego',
           friends => [ 'me', 'you' ],
           enemies => { loathsome => 'Bill Gates',
                        fearsome => 'Larry Ellison' },
         };
 $text = $template->fill_in(HASH => $hash, ...);
 # $recipient is Abed-Nego,
 # @friends is ( 'me', 'you' ),
 # %enemies is ( loathsome => ..., fearsome => ... )

 # Call &callback in case of programming errors in template
 $text = $template->fill_in(BROKEN => \&callback, BROKEN_ARG => $ref, ...);

 # Evaluate program fragments in Safe compartment with restricted permissions
 $text = $template->fill_in(SAFE => $compartment, ...);

 # Print result text instead of returning it
 $success = $template->fill_in(OUTPUT => \*FILEHANDLE, ...);

 # Parse template with different template file syntax:
 $text = $template->fill_in(DELIMITERS => [$open, $close], ...);
 # Note that this is *faster* than using the default delimiters

 # Prepend specified perl code to each fragment before evaluating:
 $text = $template->fill_in(PREPEND => q{use strict 'vars';}, ...);

 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, ...);

 # All templates will always have `use strict vars' attached to all fragments
 Text::Template->always_prepend(q{use strict 'vars';});

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.

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.

Here's an example of a template, which we'll suppose is stored in the file CWformletter.tmpl:

        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

Here is a complete program that transforms the example template into the example result, and prints it out:

        use Text::Template;

        my $template = Text::Template->new(SOURCE => 'formletter.tmpl')
          or die "Couldn't construct template: $Text::Template::ERROR";

        my @monthname = qw(January February March April May June
                           July August September October November December);
        my %vars = (title => 'Mr.',
                    firstname => 'Bill',
                    lastname => 'Gates',
                    last_paid_month => 1,   # February
                    amount => 392.12,
                    monthname => \@monthname,
                   );

        my $result = $template->fill_in(HASH => \%vars);

        if (defined $result) { print $result }
        else { die "Couldn't fill in template: $Text::Template::ERROR" }

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 CW%%VAR%% is replaced with the value of CW$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?

CWText::Template templates are programmed in Perl. You embed Perl code in your template, with CW{ at the beginning and CW} 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.

The CWText::Template module scans the template source. An open brace CW{ begins a program fragment, which continues until the matching close brace CW}. 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 CW\ in front of a brace (or another backslash that is in front of a brace) escapes its special meaning. The result of filling out this template:

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

is

        { The sum of 1 and 2 is 3  }

If you have an unmatched brace, CWText::Template will return a failure code and a warning about where the problem is. Backslashes that do not precede a brace are passed through unchanged. If you have a template like this:

        { "String that ends in a newline.\n" }

The backslash inside the string is passed through to Perl unchanged, so the CW\n really does turn into a newline. See the note at the end for details about the way backslashes work. Backslash processing is not done when you specify alternative delimiters with the CWDELIMITERS option. (See Alternative Delimiters, below.)

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 CW$x set in the first line will persist into the next fragment that begins on the third line, and the values of CW$diff and CW$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 25 more than he gave me last year.

That is all the syntax there is. There is one special trick you can play in a template. Here is the motivation for it: Suppose you are going to pass an array, CW@items, into the template, and you want the template to generate a bulleted list with a header, like this:

        Here is a list of the things I have got for you since 1907:
          * Ivory
          * Apes
          * Peacocks
          * ...

One way to do it is with a template like this:

        Here is a list of the things I have got for you since 1907:
        { my $blist = '';
          foreach $i (@items) {
            $blist .= qq{  * $i\n};
          }    
          $blist;
        }

Here we construct the list in a variable called CW$blist, which we return at the end. This is a little cumbersome. There is a shortcut.

Inside of templates, there is a special variable called CW$OUT. Anything you append to this variable will appear in the output of the template. Also, if you use CW$OUT in a program fragment, the normal behavior, of replacing the fragment with its return value, is disabled; instead the fragment is replaced with the value of CW$OUT. This means that you can write the template above like this:

        Here is a list of the things I have got for you since 1907:
        { foreach $i (@items) {
            $OUT .= "  * $i\n";
          }    
        }

CW$OUT is reinitialized to the empty string at the start of each program fragment. It is private to CWText::Template, so you can't use a variable named CW$OUT in your template without invoking the special behavior.

All CWText::Template functions return CWundef on failure, and set the variable CW$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, CW$Text::Template::ERROR will contain something like:

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

        $template = new Text::Template ( TYPE => ..., SOURCE => ... );

This creates and returns a new template object. CWnew returns CWundef and sets CW$Text::Template::ERROR if it can't create the template object. CWSOURCE says where the template source code will come from. CWTYPE says what kind of object the source is.

The most common type of source is a file:

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

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

The CWTYPE can also be CWSTRING, in which case the CWSOURCE should be a string:

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

The CWTYPE can be CWARRAY, 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 CWTYPE can be FILEHANDLE, in which case the source should be an open filehandle (such as you got from the CWFileHandle or CWIO::* packages, or a glob, or a reference to a glob). In this case CWText::Template will read the text from the filehandle up to end-of-file, and that text is the template:

        # Read template source code from STDIN:
        new Text::Template ( TYPE => 'FILEHANDLE', 
                             SOURCE => \*STDIN  );

If you omit the CWTYPE attribute, it's taken to be CWFILE. CWSOURCE is required. If you omit it, the program will abort.

The words CWTYPE and CWSOURCE 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. You may also add a CWDELIMITERS option. If this option is present, its value should be a reference to an array of two strings. The first string is the string that signals the beginning of each program fragment, and the second string is the string that signals the end of each program fragment. See Alternative Delimiters, below. If your program is running in taint mode, you may have problems if your templates are stored in files. Data read from files is considered 'untrustworthy', and taint mode will not allow you to evaluate the Perl code in the file. (It is afraid that a malicious person might have tampered with the file.) In some environments, however, local files are trustworthy. You can tell CWText::Template that a certain file is trustworthy by supplying CWUNTAINT => 1 in the call to CWnew. This will tell CWText::Template to disable taint checks on template code that has come from a file, as long as the filename itself is considered trustworthy. It will also disable taint checks on template code that comes from a filehandle. When used with CWTYPE => 'string' or CWTYPE => 'array', it has no effect. See perlsec for more complete information about tainting. Thanks to Steve Palincsar, Gerard Vreeswijk, and Dr. Christoph Baehr for help with this feature. This option is passed along to the CWfill_in call unless it is overridden in the arguments to CWfill_in. See "CWPREPEND feature and using CWstrict in templates" below. This option is passed along to the CWfill_in call unless it is overridden in the arguments to CWfill_in. See CWBROKEN below.

        $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 CW$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 CWfill_in (see below) compiles the template if it isn't compiled already.

If there is an argument to this function, it must be a reference to an array containing alternative delimiter strings. See CW"Alternative Delimiters", below.

        $template->fill_in(OPTIONS);

Fills in a template. Returns the resulting text if successful. Otherwise, returns CWundef and sets CW$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 CWPACKAGE (for example) 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 eight legal options: CWPACKAGE, CWBROKEN, CWBROKEN_ARG, CWSAFE, CWHASH, CWOUTPUT, and CWDELIMITERS. CWPACKAGE specifies the name of a package in which the program fragments should be evaluated. The default is to use the package from which CWfill_in was called. For example, consider this template:

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

        Your Royal Highness,

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

        { foreach $item (@items) {
            $item_no++;
            $OUT .= " $item_no. \u$item\n";
          }
        }

        Signed,
        Lord High Chamberlain

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

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

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

*

If the value is CWundef, then any variables named CW$key, CW@key, CW%key, etc., are undefined.

*

If the value is a string or a number, then CW$key is set to that value in the template.

*

For anything else, you must pass a reference. If the value is a reference to an array, then CW@key is set to that array. If the value is a reference to a hash, then CW%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.)

*

In particular, if you want the template to get an object or any kind, you must pass a reference to it:

        $template->fill_in(HASH => { database_handle => \$dbh, ... });

If you do this, the template will have a variable CW$database_handle which is the database handle object. If you leave out the CW\, the template will have a hash CW%database_handle, which exposes the internal structure of the database handle object; you don't want that. 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 CWPACKAGE option, CWText::Template loads the variables into the package you specified, and they stay there after the call returns. Subsequent calls to CWfill_in that use the same package will pick up the values you loaded in. If the argument of CWHASH 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 CW$v to CW"The King" and CW@v to CW(1,2,3). If any of the program fragments fails to compile or aborts for any reason, and you have set the CWBROKEN option to a function reference, CWText::Template will invoke the function. This function is called the CIBROKEN function. The CWBROKEN function will tell CWText::Template what to do next. If the CWBROKEN function returns CWundef, CWText::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 CWfill_in returns so that you can tell whether there was a premature return or not. If the CWBROKEN 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. For example, if the CWBROKEN function returns an error string, the error string will be interpolated into the output of the template in place of the program fragment that cased the error. If you don't specify a CWBROKEN function, CWText::Template supplies a default one that returns something like

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

(Note that the format of this message has changed slightly since version 1.31.) The return value of the CWBROKEN function is interpolated into the template at the place the error occurred, so that this template:

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

yields this result:

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

If you specify a value for the CWBROKEN attribute, it should be a reference to a function that CWfill_in can call instead of the default function. CWfill_in will pass a hash to the CWbroken function. The hash will have at least these three members: The source code of the program fragment that failed The text of the error message (CW$@) generated by eval. The text has been modified to omit the trailing newline and to include the name of the template file (if there was one). The line number counts from the beginning of the template, not from the beginning of the failed program fragment. The line number of the template at which the program fragment began. There may also be an CWarg member. See CWBROKEN_ARG, below If you supply the CWBROKEN_ARG option to CWfill_in, the value of the option is passed to the CWBROKEN function whenever it is called. The default CWBROKEN function ignores the CWBROKEN_ARG, but you can write a custom CWBROKEN function that uses the CWBROKEN_ARG to get more information about what went wrong. The CWBROKEN function could also use the CWBROKEN_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 CWBROKEN function, CWmy_broken, and pass it the CWBROKEN_ARG, which is a reference to CW$error. CWmy_broken can store an error message into CW$error this way. Then the function that called CWfill_in can see if CWmy_broken has left an error message for it to find, and proceed accordingly. If you give CWfill_in a CWSAFE option, its value should be a safe compartment object from the CWSafe package. All evaluation of program fragments will be performed in this compartment. See Safe for full details about such compartments and how to restrict the operations that can be performed in them. If you use the CWPACKAGE option with CWSAFE, the package you specify will be placed into the safe compartment and evaluation will take place in that package as usual. If not, CWSAFE operation is a little different from the default. Usually, if you don't specify a package, evaluation of program fragments occurs in the package from which the template was invoked. But in CWSAFE mode the evaluation occurs inside the safe compartment and cannot affect the calling package. Normally, if you use CWHASH without CWPACKAGE, the hash variables are imported into a private, one-use-only package. But if you use CWHASH and CWSAFE together without CWPACKAGE, the hash variables will just be loaded into the root namespace of the CWSafe compartment. If your template is going to generate a lot of text that you are just going to print out again anyway, you can save memory by having CWText::Template print out the text as it is generated instead of making it into a big string and returning the string. If you supply the CWOUTPUT option to CWfill_in, the value should be a filehandle. The generated text will be printed to this filehandle as it is constructed. For example:

        $template->fill_in(OUTPUT => \*STDOUT, ...);

fills in the CW$template as usual, but the results are immediately printed to STDOUT. This may result in the output appearing more quickly than it would have otherwise. If you use CWOUTPUT, the return value from CWfill_in is still true on success and false on failure, but the complete text is not returned to the caller. You can have some Perl code prepended automatically to the beginning of every program fragment. See "CWPREPEND feature and using CWstrict in templates" below. If this option is present, its value should be a reference to a list of two strings. The first string is the string that signals the beginning of each program fragment, and the second string is the string that signals the end of each program fragment. See Alternative Delimiters, below. If you specify CWDELIMITERS in the call to CWfill_in, they override any delimiters you set when you created the template object with CWnew.

The basic way to fill in a template is to create a template object and then call CWfill_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. CWfill_this_in accepts a string, which contains the template, and a list of options, which are passed to CWfill_in as above. It constructs the template object for you, fills it in as specified, and returns the results. It returns CWundef and sets CW$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 CW<< notation.

CWfill_this_in is a deprecated feature. It is only here for backwards compatibility, and may be removed in some far-future version in CWText::Template. You should use CWfill_in_string instead. It is described in the next section. It is stupid that CWfill_this_in is a class method. It should have been just an imported function, so that you could omit the CWText::Template-> in the example above. But I made the mistake four years ago and it is too late to change it.

CWfill_in_string is exactly like CWfill_this_in except that it is not a method and you can omit the CWText::Template-> and just say

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

To use CWfill_in_string, you need to say

        use Text::Template 'fill_in_string';

at the top of your program. You should probably use CWfill_in_string instead of CWfill_this_in. If you import CWfill_in_file, you can say

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

The CW... are passed to CWfill_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 CWundef, as usual.

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

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 CWcat, 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 CWfill_in call is package CWQ. Then in the main program, write

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

This imports the CW_load_text function into package CWQ with the name CWinclude. From then on, any template that you fill in with package CWQ can say

        {include(filename)}

to insert the text from the named file at that point. If you are using the CWHASH option instead, just put CWinclude => \&Text::Template::_load_text into the hash instead of importing it explicitly.

Suppose you don't want to insert a plain text file, but rather you want to include one template within another? Just use CWfill_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.

People are frequently surprised when this doesn't work:

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

The text CWThe King doesn't get into the form letter. Why not? Because CW$recipient is a CWmy variable, and the whole point of CWmy 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 CW$recipient.

If that's not the behavior you want, don't use CWmy. CWmy means a private variable, and in this case you don't want the variable to be private. Put the variables into package variables in some other package, and use the CWPACKAGE option to CWfill_in:

        $Q::recipient = $recipient;
        my $text = fill_in_file('formletter.tmpl', PACKAGE => 'Q');

or pass the names and values in a hash with the CWHASH option:

        my $text = fill_in_file('formletter.tmpl', HASH => { recipient => $recipient });

All variables are evaluated in the package you specify with the CWPACKAGE option of CWfill_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 CWSafe) to protect against a template that says

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

or

        { $/ = "ho ho ho";   # 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, or you can't trust the person who wrote the template, use the CWSAFE option.

A final warning: program fragments run a small risk of accidentally clobbering local variables in the CWfill_in function itself. These variables all have names that begin with CW$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; this is actually how CW$OUT works.) I can fix this, but it will make the package slower to do it, so I would prefer not to. If you are worried about this, send me mail and I will show you what to do about it.

Lorenzo Valdettaro pointed out that if you are using CWText::Template to generate TeX output, the choice of braces as the program fragment delimiters makes you suffer suffer suffer. Starting in version 1.20, you can change the choice of delimiters to something other than curly braces.

In either the CWnew() call or the CWfill_in() call, you can specify an alternative set of delimiters with the CWDELIMITERS option. For example, if you would like code fragments to be delimited by CW[@-- and CW--@] instead of CW{ and CW}, use

        ... DELIMITERS => [ '[@--', '--@]' ], ...

Note that these delimiters are literal strings, not regexes. (I tried for regexes, but it complicates the lexical analysis too much.) Note also that CWDELIMITERS disables the special meaning of the backslash, so if you want to include the delimiters in the literal text of your template file, you are out of luck---it is up to you to choose delimiters that do not conflict with what you are doing. The delimiter strings may still appear inside of program fragments as long as they nest properly. This means that if for some reason you absolutely must have a program fragment that mentions one of the delimiters, like this:

        [@--
                print "Oh no, a delimiter: --@]\n"
        --@]

you may be able to make it work by doing this instead:

        [@--
                # Fake matching delimiter in a comment: [@--
                print "Oh no, a delimiter: --@]\n"
        --@]

It may be safer to choose delimiters that begin with a newline character.

Because the parsing of templates is simplified by the absence of backslash escapes, using alternative CWDELIMITERS speeds up the parsing process by 20-25%. This shows that my original choice of CW{ and CW} was very bad. I therefore recommend that you use alternative delimiters whenever possible. Suppose you would like to use CWstrict in your templates to detect undeclared variables and the like. But each code fragment is a separate lexical scope, so you have to turn on CWstrict at the top of each and every code fragment:

        { use strict;
          use vars '$foo';
          $foo = 14;
          ...
        }

        ...

        { # we forgot to put `use strict' here
          my $result = $boo + 12;    # $boo is misspelled and should be $foo
          # No error is raised on `$boo'
        }

Because we didn't put CWuse strict at the top of the second fragment, it was only active in the first fragment, and we didn't get any CWstrict checking in the second fragment. Then we mispelled CW$foo and the error wasn't caught.

CWText::Template version 1.22 and higher has a new feature to make this easier. You can specify that any text at all be automatically added to the beginning of each program fragment.

When you make a call to CWfill_in, you can specify a

        PREPEND => 'some perl statements here'

option; the statements will be prepended to each program fragment for that one call only. Suppose that the CWfill_in call included a

        PREPEND => 'use strict;'

option, and that the template looked like this:

        { use vars '$foo';
          $foo = 14;
          ...
        }

        ...

        { my $result = $boo + 12;    # $boo is misspelled and should be $foo
          ...
        }

The code in the second fragment would fail, because CW$boo has not been declared. CWuse strict was implied, even though you did not write it explicitly, because the CWPREPEND option added it for you automatically.

There are two other ways to do this. At the time you create the template object with CWnew, you can also supply a CWPREPEND option, in which case the statements will be prepended each time you fill in that template. If the CWfill_in call has its own CWPREPEND option, this overrides the one specified at the time you created the template. Finally, you can make the class method call

        Text::Template->always_prepend('perl statements');

If you do this, then call calls to CWfill_in for any template will attach the perl statements to the beginning of each program fragment, except where overridden by CWPREPEND options to CWnew or CWfill_in.

This section is technical, and you should skip it on the first few readings.

Normally there are three places that prepended text could come from. It could come from the CWPREPEND option in the CWfill_in call, from the CWPREPEND option in the CWnew call that created the template object, or from the argument of the CWalways_prepend call. CWText::Template looks for these three things in order and takes the first one that it finds.

In a subclass of CWText::Template, this last possibility is ambiguous. Suppose CWS is a subclass of CWText::Template. Should

        Text::Template->always_prepend(...);

affect objects in class CWDerived? The answer is that you can have it either way.

The CWalways_prepend value for CWText::Template is normally stored in a hash variable named CW%GLOBAL_PREPEND under the key CWText::Template. When CWText::Template looks to see what text to prepend, it first looks in the template object itself, and if not, it looks in CW$GLOBAL_PREPEND{CIclassCW} where class is the class to which the template object belongs. If it doesn't find any value, it looks in CW$GLOBAL_PREPEND{'Text::Template'}. This means that objects in class CWDerived will be affected by

        Text::Template->always_prepend(...);

unless there is also a call to

        Derived->always_prepend(...);

So when you're designing your derived class, you can arrange to have your objects ignore CWText::Template::always_prepend calls by simply putting CWDerived->always_prepend('') at the top of your module.

Of course, there is also a final escape hatch: Templates support a CWprepend_text that is used to look up the appropriate text to be prepended at CWfill_in time. Your derived class can override this method to get an arbitrary effect.

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 ensue when perl tries to evaluate these as if they were Perl programs. The best choice is to find some unambiguous delimiter strings that you can use in your template instead of curly braces, and then use the CWDELIMITERS option. However, if you can't do this for some reason, there are two easy workarounds:

1. You can put CW\ in front of CW{, CW}, or CW\ 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, CWq{...} is the same as CW'...'. So if we wrote

            {q{foo}}

it would turn into

            foo

So for your JavaScript, just write

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

and it'll come out as

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

which is what you want.

People sometimes try to put an initialization section at the top of their templates, like this:

        { ...
          $var = 17;
        }

Then they complain because there is a CW17 at the top of the output that they didn't want to have there.

Remember that a program fragment is replaced with its own return value, and that in Perl the return value of a code block is the value of the last expression that was evaluated, which in this case is 17. If it didn't do that, you wouldn't be able to write CW{$recipient} and have the recipient filled in.

To prevent the 17 from appearing in the output is very simple:

        { ...
          $var = 17;
          '';
        }

Now the last expression evaluated yields the empty string, which is invisible. If you don't like the way this looks, use

        { ...
          $var = 17;
          ($SILENTLY);
        }

instead. Presumably, CW$SILENTLY has no value, so nothing will be interpolated. This is what is known as a `trick'.

Every effort has been made to make this module compatible with older versions. The only known exceptions follow:

The output format of the default CWBROKEN subroutine has changed twice, most recently between versions 1.31 and 1.40.

Starting in version 1.10, the CW$OUT variable is arrogated for a special meaning. If you had templates before version 1.10 that happened to use a variable named CW$OUT, you will have to change them to use some other variable or all sorts of strangeness will result.

Between versions 0.1b and 1.00 the behavior of the \ metacharacter changed. In 0.1b, \\ was special everywhere, and the template processor always replaced it with a single backslash before passing the code to Perl for evaluation. The rule now is more complicated but probably more convenient. See the section on backslash processing, below, for a full discussion.

In CWText::Template beta versions, the backslash was special whenever it appeared before a brace or another backslash. That meant that while CW{"\n"} did indeed generate a newline, CW{"\\"} did not generate a backslash, because the code passed to Perl for evaluation was CW"\" which is a syntax error. If you wanted a backslash, you would have had to write CW{"\\\\"}.

In CWText::Template versions 1.00 through 1.10, there was a bug: Backslash was special everywhere. In these versions, CW{"\n"} generated the letter CWn.

The bug has been corrected in version 1.11, but I did not go back to exactly the old rule, because I did not like the idea of having to write CW{"\\\\"} to get one backslash. The rule is now more complicated to remember, but probably easier to use. The rule is now: Backslashes are always passed to Perl unchanged unless they occur as part of a sequence like CW\\\\\\{ or CW\\\\\\}. In these contexts, they are special; CW\\ is replaced with CW\, and CW\{ and CW\} signal a literal brace.

Examples:

        \{ foo \}

is not evaluated, because the CW\ before the braces signals that they should be taken literally. The result in the output looks like this:

        { foo }

This is a syntax error:

        { "foo}" }

because CWText::Template thinks that the code ends at the first CW}, and then gets upset when it sees the second one. To make this work correctly, use

        { "foo\}" }

This passes CW"foo}" to Perl for evaluation. Note there's no CW\ in the evaluated code. If you really want a CW\ in the evaluated code, use

        { "foo\\\}" }

This passes CW"foo\}" to Perl for evaluation.

Starting with CWText::Template version 1.20, backslash processing is disabled if you use the CWDELIMITERS option to specify alternative delimiter strings. In the past some people have fretted about `violating the package boundary' by examining a variable inside the CWText::Template package. Don't feel this way. CW$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 CWTTerror that returns the current value of the CW$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.

The CWCGI 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 CWCGI functions from inside the template:

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

It may be useful to preprocess the program fragments before they are evaluated. See CWText::Template::Preprocess for more details.

Mark-Jason Dominus, Plover Systems

Please send questions and other remarks about this software to CWmjd-perl-template+@plover.com

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

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

This software is version 1.44. It may have bugs. Suggestions and bug reports are always welcome. Send them to CWmjd-perl-template+@plover.com. (That is my address, not the address of the mailing list. The mailing list address is a secret.)

    Text::Template version 1.44
    Copyright (C) 2003 Mark Jason Dominus

    This program is free software; you can redistribute it and/or
    modify it under the terms of the GNU General Public License as
    published by the Free Software Foundation; either version 2 of the
    License, or (at your option) any later version.  You may also can
    redistribute it and/or modify it under the terms of the Perl
    Artistic License.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received copies of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Many thanks to the following people for offering support, encouragement, advice, bug reports, and all the other good stuff.

David H. Adler / Joel Appelbaum / Klaus Arnhold / Anto'nio Araga~o / Kevin Atteson / Chris.Brezil / Mike Brodhead / Tom Brown / Dr. Frank Bucolo / Tim Bunce / Juan E. Camacho / Itamar Almeida de Carvalho / Joseph Cheek / Gene Damon / San Deng / Bob Dougherty / Marek Grac / Dan Franklin / gary at dls.net / Todd A. Green / Donald L. Greer Jr. / Michelangelo Grigni / Zac Hansen / Tom Henry / Jarko Hietaniemi / Matt X. Hunter / Robert M. Ioffe / Daniel LaLiberte / Reuven M. Lerner / Trip Lilley / Yannis Livassof / Val Luck / Kevin Madsen / David Marshall / James Mastros / Joel Meulenberg / Jason Moore / Sergey Myasnikov / Chris Nandor / Bek Oberin / Steve Palincsar / Ron Pero / Hans Persson / Sean Roehnelt / Jonathan Roy / Shabbir J. Safdar / Jennifer D. St Clair / Uwe Schneider / Randal L. Schwartz / Michael G Schwern / Yonat Sharon / Brian C. Shensky / Niklas Skoglund / Tom Snee / Fred Steinberg / Hans Stoop / Michael J. Suzio / Dennis Taylor / James H. Thompson / Shad Todd / Lieven Tomme / Lorenzo Valdettaro / Larry Virden / Andy Wardley / Archie Warnock / Chris Wesley / Matt Womer / Andrew G Wood / Daini Xie / Michaely Yeung

Special thanks to:

Jonathan Roy

for telling me how to do the CWSafe support (I spent two years worrying about it, and then Jonathan pointed out that it was trivial.)

Ranjit Bhatnagar

for demanding less verbose fragments like they have in ASP, for helping me figure out the Right Thing, and, especially, for talking me out of adding any new syntax. These discussions resulted in the CW$OUT feature.

CWmy variables in CWfill_in are still susceptible to being clobbered by template evaluation. They all begin with CWfi_, so avoid those names in your templates.

The line number information will be wrong if the template's lines are not terminated by CW"\n". You should let me know if this is a problem. If you do, I will fix it.

The CW$OUT variable has a special meaning in templates, so you cannot use it as if it were a regular variable.

There are not quite enough tests in the test suite.