+# -*- perl -*-
+# Text::Template.pm
+#
+# Fill in `templates'
+#
+# Copyright 2013 M. J. Dominus.
+# You may copy and distribute this program under the
+# same terms as Perl iteself.
+# If in doubt, write to mjd-perl-template+@plover.com for a license.
+#
+# Version 1.46
+
+package Text::Template;
+require 5.004;
+use Exporter;
+@ISA = qw(Exporter);
+@EXPORT_OK = qw(fill_in_file fill_in_string TTerror);
+use vars '$ERROR';
+use strict;
+
+$Text::Template::VERSION = '1.46';
+my %GLOBAL_PREPEND = ('Text::Template' => '');
+
+sub Version {
+ $Text::Template::VERSION;
+}
+
+sub _param {
+ my $kk;
+ my ($k, %h) = @_;
+ for $kk ($k, "\u$k", "\U$k", "-$k", "-\u$k", "-\U$k") {
+ return $h{$kk} if exists $h{$kk};
+ }
+ return;
+}
+
+sub always_prepend
+{
+ my $pack = shift;
+ my $old = $GLOBAL_PREPEND{$pack};
+ $GLOBAL_PREPEND{$pack} = shift;
+ $old;
+}
+
+{
+ my %LEGAL_TYPE;
+ BEGIN {
+ %LEGAL_TYPE = map {$_=>1} qw(FILE FILEHANDLE STRING ARRAY);
+ }
+ sub new {
+ my $pack = shift;
+ my %a = @_;
+ my $stype = uc(_param('type', %a) || "FILE");
+ my $source = _param('source', %a);
+ my $untaint = _param('untaint', %a);
+ my $prepend = _param('prepend', %a);
+ my $alt_delim = _param('delimiters', %a);
+ my $broken = _param('broken', %a);
+ unless (defined $source) {
+ require Carp;
+ Carp::croak("Usage: $ {pack}::new(TYPE => ..., SOURCE => ...)");
+ }
+ unless ($LEGAL_TYPE{$stype}) {
+ require Carp;
+ Carp::croak("Illegal value `$stype' for TYPE parameter");
+ }
+ my $self = {TYPE => $stype,
+ PREPEND => $prepend,
+ UNTAINT => $untaint,
+ BROKEN => $broken,
+ (defined $alt_delim ? (DELIM => $alt_delim) : ()),
+ };
+ # Under 5.005_03, if any of $stype, $prepend, $untaint, or $broken
+ # are tainted, all the others become tainted too as a result of
+ # sharing the expression with them. We install $source separately
+ # to prevent it from acquiring a spurious taint.
+ $self->{SOURCE} = $source;
+
+ bless $self => $pack;
+ return unless $self->_acquire_data;
+
+ $self;
+ }
+}
+
+# Convert template objects of various types to type STRING,
+# in which the template data is embedded in the object itself.
+sub _acquire_data {
+ my ($self) = @_;
+ my $type = $self->{TYPE};
+ if ($type eq 'STRING') {
+ # nothing necessary
+ } elsif ($type eq 'FILE') {
+ my $data = _load_text($self->{SOURCE});
+ unless (defined $data) {
+ # _load_text already set $ERROR
+ return undef;
+ }
+ if ($self->{UNTAINT} && _is_clean($self->{SOURCE})) {
+ _unconditionally_untaint($data);
+ }
+ $self->{TYPE} = 'STRING';
+ $self->{FILENAME} = $self->{SOURCE};
+ $self->{SOURCE} = $data;
+ } elsif ($type eq 'ARRAY') {
+ $self->{TYPE} = 'STRING';
+ $self->{SOURCE} = join '', @{$self->{SOURCE}};
+ } elsif ($type eq 'FILEHANDLE') {
+ $self->{TYPE} = 'STRING';
+ local $/;
+ my $fh = $self->{SOURCE};
+ my $data = <$fh>; # Extra assignment avoids bug in Solaris perl5.00[45].
+ if ($self->{UNTAINT}) {
+ _unconditionally_untaint($data);
+ }
+ $self->{SOURCE} = $data;
+ } else {
+ # This should have been caught long ago, so it represents a
+ # drastic `can't-happen' sort of failure
+ my $pack = ref $self;
+ die "Can only acquire data for $pack objects of subtype STRING, but this is $type; aborting";
+ }
+ $self->{DATA_ACQUIRED} = 1;
+}
+
+sub source {
+ my ($self) = @_;
+ $self->_acquire_data unless $self->{DATA_ACQUIRED};
+ return $self->{SOURCE};
+}
+
+sub set_source_data {
+ my ($self, $newdata) = @_;
+ $self->{SOURCE} = $newdata;
+ $self->{DATA_ACQUIRED} = 1;
+ $self->{TYPE} = 'STRING';
+ 1;
+}
+
+sub compile {
+ my $self = shift;
+
+ return 1 if $self->{TYPE} eq 'PREPARSED';
+
+ return undef unless $self->_acquire_data;
+ unless ($self->{TYPE} eq 'STRING') {
+ my $pack = ref $self;
+ # This should have been caught long ago, so it represents a
+ # drastic `can't-happen' sort of failure
+ die "Can only compile $pack objects of subtype STRING, but this is $self->{TYPE}; aborting";
+ }
+
+ my @tokens;
+ my $delim_pats = shift() || $self->{DELIM};
+
+
+
+ my ($t_open, $t_close) = ('{', '}');
+ my $DELIM; # Regex matches a delimiter if $delim_pats
+ if (defined $delim_pats) {
+ ($t_open, $t_close) = @$delim_pats;
+ $DELIM = "(?:(?:\Q$t_open\E)|(?:\Q$t_close\E))";
+ @tokens = split /($DELIM|\n)/, $self->{SOURCE};
+ } else {
+ @tokens = split /(\\\\(?=\\*[{}])|\\[{}]|[{}\n])/, $self->{SOURCE};
+ }
+ my $state = 'TEXT';
+ my $depth = 0;
+ my $lineno = 1;
+ my @content;
+ my $cur_item = '';
+ my $prog_start;
+ while (@tokens) {
+ my $t = shift @tokens;
+ next if $t eq '';
+ if ($t eq $t_open) { # Brace or other opening delimiter
+ if ($depth == 0) {
+ push @content, [$state, $cur_item, $lineno] if $cur_item ne '';
+ $cur_item = '';
+ $state = 'PROG';
+ $prog_start = $lineno;
+ } else {
+ $cur_item .= $t;
+ }
+ $depth++;
+ } elsif ($t eq $t_close) { # Brace or other closing delimiter
+ $depth--;
+ if ($depth < 0) {
+ $ERROR = "Unmatched close brace at line $lineno";
+ return undef;
+ } elsif ($depth == 0) {
+ push @content, [$state, $cur_item, $prog_start] if $cur_item ne '';
+ $state = 'TEXT';
+ $cur_item = '';
+ } else {
+ $cur_item .= $t;
+ }
+ } elsif (!$delim_pats && $t eq '\\\\') { # precedes \\\..\\\{ or \\\..\\\}
+ $cur_item .= '\\';
+ } elsif (!$delim_pats && $t =~ /^\\([{}])$/) { # Escaped (literal) brace?
+ $cur_item .= $1;
+ } elsif ($t eq "\n") { # Newline
+ $lineno++;
+ $cur_item .= $t;
+ } else { # Anything else
+ $cur_item .= $t;
+ }
+ }
+
+ if ($state eq 'PROG') {
+ $ERROR = "End of data inside program text that began at line $prog_start";
+ return undef;
+ } elsif ($state eq 'TEXT') {
+ push @content, [$state, $cur_item, $lineno] if $cur_item ne '';
+ } else {
+ die "Can't happen error #1";
+ }
+
+ $self->{TYPE} = 'PREPARSED';
+ $self->{SOURCE} = \@content;
+ 1;
+}
+
+sub prepend_text {
+ my ($self) = @_;
+ my $t = $self->{PREPEND};
+ unless (defined $t) {
+ $t = $GLOBAL_PREPEND{ref $self};
+ unless (defined $t) {
+ $t = $GLOBAL_PREPEND{'Text::Template'};
+ }
+ }
+ $self->{PREPEND} = $_[1] if $#_ >= 1;
+ return $t;
+}
+
+sub fill_in {
+ my $fi_self = shift;
+ my %fi_a = @_;
+
+ unless ($fi_self->{TYPE} eq 'PREPARSED') {
+ my $delims = _param('delimiters', %fi_a);
+ my @delim_arg = (defined $delims ? ($delims) : ());
+ $fi_self->compile(@delim_arg)
+ or return undef;
+ }
+
+ my $fi_varhash = _param('hash', %fi_a);
+ my $fi_package = _param('package', %fi_a) ;
+ my $fi_broken =
+ _param('broken', %fi_a) || $fi_self->{BROKEN} || \&_default_broken;
+ my $fi_broken_arg = _param('broken_arg', %fi_a) || [];
+ my $fi_safe = _param('safe', %fi_a);
+ my $fi_ofh = _param('output', %fi_a);
+ my $fi_eval_package;
+ my $fi_scrub_package = 0;
+ my $fi_filename = _param('filename') || $fi_self->{FILENAME} || 'template';
+
+ my $fi_prepend = _param('prepend', %fi_a);
+ unless (defined $fi_prepend) {
+ $fi_prepend = $fi_self->prepend_text;
+ }
+
+ if (defined $fi_safe) {
+ $fi_eval_package = 'main';
+ } elsif (defined $fi_package) {
+ $fi_eval_package = $fi_package;
+ } elsif (defined $fi_varhash) {
+ $fi_eval_package = _gensym();
+ $fi_scrub_package = 1;
+ } else {
+ $fi_eval_package = caller;
+ }
+
+ my $fi_install_package;
+ if (defined $fi_varhash) {
+ if (defined $fi_package) {
+ $fi_install_package = $fi_package;
+ } elsif (defined $fi_safe) {
+ $fi_install_package = $fi_safe->root;
+ } else {
+ $fi_install_package = $fi_eval_package; # The gensymmed one
+ }
+ _install_hash($fi_varhash => $fi_install_package);
+ }
+
+ if (defined $fi_package && defined $fi_safe) {
+ no strict 'refs';
+ # Big fat magic here: Fix it so that the user-specified package
+ # is the default one available in the safe compartment.
+ *{$fi_safe->root . '::'} = \%{$fi_package . '::'}; # LOD
+ }
+
+ my $fi_r = '';
+ my $fi_item;
+ foreach $fi_item (@{$fi_self->{SOURCE}}) {
+ my ($fi_type, $fi_text, $fi_lineno) = @$fi_item;
+ if ($fi_type eq 'TEXT') {
+ $fi_self->append_text_to_output(
+ text => $fi_text,
+ handle => $fi_ofh,
+ out => \$fi_r,
+ type => $fi_type,
+ );
+ } elsif ($fi_type eq 'PROG') {
+ no strict;
+ my $fi_lcomment = "#line $fi_lineno $fi_filename";
+ my $fi_progtext =
+ "package $fi_eval_package; $fi_prepend;\n$fi_lcomment\n$fi_text;";
+ my $fi_res;
+ my $fi_eval_err = '';
+ if ($fi_safe) {
+ $fi_safe->reval(q{undef $OUT});
+ $fi_res = $fi_safe->reval($fi_progtext);
+ $fi_eval_err = $@;
+ my $OUT = $fi_safe->reval('$OUT');
+ $fi_res = $OUT if defined $OUT;
+ } else {
+ my $OUT;
+ $fi_res = eval $fi_progtext;
+ $fi_eval_err = $@;
+ $fi_res = $OUT if defined $OUT;
+ }
+
+ # If the value of the filled-in text really was undef,
+ # change it to an explicit empty string to avoid undefined
+ # value warnings later.
+ $fi_res = '' unless defined $fi_res;
+
+ if ($fi_eval_err) {
+ $fi_res = $fi_broken->(text => $fi_text,
+ error => $fi_eval_err,
+ lineno => $fi_lineno,
+ arg => $fi_broken_arg,
+ );
+ if (defined $fi_res) {
+ $fi_self->append_text_to_output(
+ text => $fi_res,
+ handle => $fi_ofh,
+ out => \$fi_r,
+ type => $fi_type,
+ );
+ } else {
+ return $fi_res; # Undefined means abort processing
+ }
+ } else {
+ $fi_self->append_text_to_output(
+ text => $fi_res,
+ handle => $fi_ofh,
+ out => \$fi_r,
+ type => $fi_type,
+ );
+ }
+ } else {
+ die "Can't happen error #2";
+ }
+ }
+
+ _scrubpkg($fi_eval_package) if $fi_scrub_package;
+ defined $fi_ofh ? 1 : $fi_r;
+}
+
+sub append_text_to_output {
+ my ($self, %arg) = @_;
+
+ if (defined $arg{handle}) {
+ print { $arg{handle} } $arg{text};
+ } else {
+ ${ $arg{out} } .= $arg{text};
+ }
+
+ return;
+}
+
+sub fill_this_in {
+ my $pack = shift;
+ my $text = shift;
+ my $templ = $pack->new(TYPE => 'STRING', SOURCE => $text, @_)
+ or return undef;
+ $templ->compile or return undef;
+ my $result = $templ->fill_in(@_);
+ $result;
+}
+
+sub fill_in_string {
+ my $string = shift;
+ my $package = _param('package', @_);
+ push @_, 'package' => scalar(caller) unless defined $package;
+ Text::Template->fill_this_in($string, @_);
+}
+
+sub fill_in_file {
+ my $fn = shift;
+ my $templ = Text::Template->new(TYPE => 'FILE', SOURCE => $fn, @_)
+ or return undef;
+ $templ->compile or return undef;
+ my $text = $templ->fill_in(@_);
+ $text;
+}
+
+sub _default_broken {
+ my %a = @_;
+ my $prog_text = $a{text};
+ my $err = $a{error};
+ my $lineno = $a{lineno};
+ chomp $err;
+# $err =~ s/\s+at .*//s;
+ "Program fragment delivered error ``$err''";
+}
+
+sub _load_text {
+ my $fn = shift;
+ local *F;
+ unless (open F, $fn) {
+ $ERROR = "Couldn't open file $fn: $!";
+ return undef;
+ }
+ local $/;
+ <F>;
+}
+
+sub _is_clean {
+ my $z;
+ eval { ($z = join('', @_)), eval '#' . substr($z,0,0); 1 } # LOD
+}
+
+sub _unconditionally_untaint {
+ for (@_) {
+ ($_) = /(.*)/s;
+ }
+}
+
+{
+ my $seqno = 0;
+ sub _gensym {
+ __PACKAGE__ . '::GEN' . $seqno++;
+ }
+ sub _scrubpkg {
+ my $s = shift;
+ $s =~ s/^Text::Template:://;
+ no strict 'refs';
+ my $hash = $Text::Template::{$s."::"};
+ foreach my $key (keys %$hash) {
+ undef $hash->{$key};
+ }
+ }
+}
+
+# Given a hashful of variables (or a list of such hashes)
+# install the variables into the specified package,
+# overwriting whatever variables were there before.
+sub _install_hash {
+ my $hashlist = shift;
+ my $dest = shift;
+ if (UNIVERSAL::isa($hashlist, 'HASH')) {
+ $hashlist = [$hashlist];
+ }
+ my $hash;
+ foreach $hash (@$hashlist) {
+ my $name;
+ foreach $name (keys %$hash) {
+ my $val = $hash->{$name};
+ no strict 'refs';
+ local *SYM = *{"$ {dest}::$name"};
+ if (! defined $val) {
+ delete ${"$ {dest}::"}{$name};
+ } elsif (ref $val) {
+ *SYM = $val;
+ } else {
+ *SYM = \$val;
+ }
+ }
+ }
+}
+
+sub TTerror { $ERROR }
+
+1;
+
+
+=head1 NAME
+
+Text::Template - Expand template text with embedded Perl
+
+=head1 VERSION
+
+This file documents C<Text::Template> version B<1.46>
+
+=head1 SYNOPSIS
+
+ 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';});
+
+=head1 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.
+
+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.
+
+=head2 Example
+
+Here's an example of a template, which we'll suppose is stored in the
+file C<formletter.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" }
+
+
+=head2 Philosophy
+
+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 C<%%VAR%%> is replaced with the
+value of C<$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?
+
+C<Text::Template> templates are programmed in I<Perl>. You embed Perl
+code in your template, with C<{> at the beginning and C<}> 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.
+
+=head1 Details
+
+=head2 Template Parsing
+
+The C<Text::Template> module scans the template source. An open brace
+C<{> begins a program fragment, which continues until the matching
+close brace C<}>. 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 C<\> 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, C<Text::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 C<\n> really does turn into a newline. See the note at the end
+for details about the way backslashes work. Backslash processing is
+I<not> done when you specify alternative delimiters with the
+C<DELIMITERS> option. (See L<"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 C<$x> set in the first line will persist into the next
+fragment that begins on the third line, and the values of C<$diff> and
+C<$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.
+
+=head2 The C<$OUT> variable
+
+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, C<@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 C<$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 C<$OUT>.
+Anything you append to this variable will appear in the output of the
+template. Also, if you use C<$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 C<$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";
+ }
+ }
+
+C<$OUT> is reinitialized to the empty string at the start of each
+program fragment. It is private to C<Text::Template>, so
+you can't use a variable named C<$OUT> in your template without
+invoking the special behavior.
+
+=head2 General Remarks
+
+All C<Text::Template> functions return C<undef> on failure, and set the
+variable C<$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, C<$Text::Template::ERROR> will contain something like:
+
+ Couldn't open file xyz.tmpl: No such file or directory
+
+=head2 C<new>
+
+ $template = new Text::Template ( TYPE => ..., SOURCE => ... );
+
+This creates and returns a new template object. C<new> returns
+C<undef> and sets C<$Text::Template::ERROR> if it can't create the
+template object. C<SOURCE> says where the template source code will
+come from. C<TYPE> 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 C<open> command, so it can be a pipe or anything
+else that makes sense with C<open>.
+
+The C<TYPE> can also be C<STRING>, in which case the C<SOURCE> should
+be a string:
+
+ new Text::Template ( TYPE => 'STRING',
+ SOURCE => "This is the actual template!" );
+
+The C<TYPE> can be C<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 C<TYPE> can be FILEHANDLE, in which case the source should be an
+open filehandle (such as you got from the C<FileHandle> or C<IO::*>
+packages, or a glob, or a reference to a glob). In this case
+C<Text::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 C<TYPE> attribute, it's taken to be C<FILE>.
+C<SOURCE> is required. If you omit it, the program will abort.
+
+The words C<TYPE> and C<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.
+
+=over 4
+
+=item C<DELIMITERS>
+
+You may also add a C<DELIMITERS> 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 L<"Alternative Delimiters">, below.
+
+=item C<UNTAINT>
+
+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 C<Text::Template> that a certain file is trustworthy by supplying
+C<UNTAINT =E<gt> 1> in the call to C<new>. This will tell
+C<Text::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 C<TYPE =E<gt> 'string'> or C<TYPE
+=E<gt> 'array'>, it has no effect.
+
+See L<perlsec> for more complete information about tainting.
+
+Thanks to Steve Palincsar, Gerard Vreeswijk, and Dr. Christoph Baehr
+for help with this feature.
+
+=item C<PREPEND>
+
+This option is passed along to the C<fill_in> call unless it is
+overridden in the arguments to C<fill_in>. See L<C<PREPEND> feature
+and using C<strict> in templates> below.
+
+=item C<BROKEN>
+
+This option is passed along to the C<fill_in> call unless it is
+overridden in the arguments to C<fill_in>. See L<C<BROKEN>> below.
+
+=back
+
+=head2 C<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 C<$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 C<fill_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 C<"Alternative
+Delimiters">, below.
+
+=head2 C<fill_in>
+
+ $template->fill_in(OPTIONS);
+
+Fills in a template. Returns the resulting text if successful.
+Otherwise, returns C<undef> and sets C<$Text::Template::ERROR>.
+
+The I<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 C<PACKAGE> (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: C<PACKAGE>, C<BROKEN>,
+C<BROKEN_ARG>, C<SAFE>, C<HASH>, C<OUTPUT>, and C<DELIMITERS>.
+
+=over 4
+
+=item C<PACKAGE>
+
+C<PACKAGE> specifies the name of a package in which the program
+fragments should be evaluated. The default is to use the package from
+which C<fill_in> was called. For example, consider this template:
+
+ The value of the variable x is {$x}.
+
+If you use C<$template-E<gt>fill_in(PACKAGE =E<gt> 'R')> , then the C<$x> in
+the template is actually replaced with the value of C<$R::x>. If you
+omit the C<PACKAGE> option, C<$x> will be replaced with the value of
+the C<$x> variable in the package that actually called C<fill_in>.
+
+You should almost always use C<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 C<PACKAGE>:
+
+ 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
+
+We want to pass in an array which will be assigned to the array
+C<@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 a variable named C<$item_no> in scope in your program at the point
+you called C<fill_in>, its value 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 way that
+the template does. (C<$OUT> is special in templates and is always
+safe.)
+
+One solution to this is to make the C<$item_no> variable private to the
+template by declaring it with C<my>. If the template does this, you
+are safe.
+
+But if you use the C<PACKAGE> option, you will probably be safe even
+if the template does I<not> declare its variables with C<my>:
+
+ @Q::items = ('ivory', 'apes', 'peacocks', );
+ $template->fill_in(PACKAGE => 'Q');
+
+In this case the template will clobber the variable C<$Q::item_no>,
+which is not related to the one your program was using.
+
+Templates cannot affect variables in the main program that are
+declared with C<my>, unless you give the template references to those
+variables.
+
+=item C<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.
+C<HASH> provides an alternative.
+
+The value for C<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'],
+ object => \$self,
+ });
+
+will fill out the template and use C<"The King"> as the value of
+C<$recipient> and the list of items as the value of C<@items>. Note
+that we pass an array reference, but inside the template it appears as
+an array. In general, anything other than a simple string or number
+should be passed by reference.
+
+We also want to pass an object, which is in C<$self>; note that we
+pass a reference to the object, C<\$self> instead. Since we've passed
+a reference to a scalar, inside the template the object appears as
+C<$object>.
+
+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 I<key> and the value is I<value>.
+
+=over 4
+
+=item *
+
+If the I<value> is C<undef>, then any variables named C<$key>,
+C<@key>, C<%key>, etc., are undefined.
+
+=item *
+
+If the I<value> is a string or a number, then C<$key> is set to that
+value in the template.
+
+=item *
+
+For anything else, you must pass a reference.
+
+If the I<value> is a reference to an array, then C<@key> is set to
+that array. If the I<value> is a reference to a hash, then C<%key> is
+set to that hash. Similarly if I<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.)
+
+=item *
+
+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 C<$database_handle>
+which is the database handle object. If you leave out the C<\>, the
+template will have a hash C<%database_handle>, which exposes the
+internal structure of the database handle object; you don't want that.
+
+=back
+
+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 I<also> use the C<PACKAGE>
+option, C<Text::Template> loads the variables into the package you
+specified, and they stay there after the call returns. Subsequent
+calls to C<fill_in> that use the same package will pick up the values
+you loaded in.
+
+If the argument of C<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 C<$v> to C<"The King"> and C<@v> to C<(1,2,3)>.
+
+=item C<BROKEN>
+
+If any of the program fragments fails to compile or aborts for any
+reason, and you have set the C<BROKEN> option to a function reference,
+C<Text::Template> will invoke the function. This function is called
+the I<C<BROKEN> function>. The C<BROKEN> function will tell
+C<Text::Template> what to do next.
+
+If the C<BROKEN> function returns C<undef>, C<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 C<fill_in> returns so that you can
+tell whether there was a premature return or not.
+
+If the C<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. For example, if the
+C<BROKEN> 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 C<BROKEN> function, C<Text::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 C<BROKEN> 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 C<BROKEN> attribute, it should be a
+reference to a function that C<fill_in> can call instead of the
+default function.
+
+C<fill_in> will pass a hash to the C<broken> function.
+The hash will have at least these three members:
+
+=over 4
+
+=item C<text>
+
+The source code of the program fragment that failed
+
+=item C<error>
+
+The text of the error message (C<$@>) 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.
+
+=item C<lineno>
+
+The line number of the template at which the program fragment began.
+
+=back
+
+There may also be an C<arg> member. See C<BROKEN_ARG>, below
+
+=item C<BROKEN_ARG>
+
+If you supply the C<BROKEN_ARG> option to C<fill_in>, the value of the
+option is passed to the C<BROKEN> function whenever it is called. The
+default C<BROKEN> function ignores the C<BROKEN_ARG>, but you can
+write a custom C<BROKEN> function that uses the C<BROKEN_ARG> to get
+more information about what went wrong.
+
+The C<BROKEN> function could also use the C<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 C<BROKEN> function, C<my_broken>, and pass it the C<BROKEN_ARG>,
+which is a reference to C<$error>. C<my_broken> can store an error
+message into C<$error> this way. Then the function that called
+C<fill_in> can see if C<my_broken> has left an error message for it
+to find, and proceed accordingly.
+
+=item C<SAFE>
+
+If you give C<fill_in> a C<SAFE> option, its value should be a safe
+compartment object from the C<Safe> package. All evaluation of
+program fragments will be performed in this compartment. See L<Safe>
+for full details about such compartments and how to restrict the
+operations that can be performed in them.
+
+If you use the C<PACKAGE> option with C<SAFE>, the package you specify
+will be placed into the safe compartment and evaluation will take
+place in that package as usual.
+
+If not, C<SAFE> 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 C<SAFE> mode the evaluation occurs inside the safe compartment
+and cannot affect the calling package. Normally, if you use C<HASH>
+without C<PACKAGE>, the hash variables are imported into a private,
+one-use-only package. But if you use C<HASH> and C<SAFE> together
+without C<PACKAGE>, the hash variables will just be loaded into the
+root namespace of the C<Safe> compartment.
+
+=item C<OUTPUT>
+
+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
+C<Text::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 C<OUTPUT> option to C<fill_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 C<$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 C<OUTPUT>, the return value from C<fill_in> is still true on
+success and false on failure, but the complete text is not returned to
+the caller.
+
+=item C<PREPEND>
+
+You can have some Perl code prepended automatically to the beginning
+of every program fragment. See L<C<PREPEND> feature and using
+C<strict> in templates> below.
+
+=item C<DELIMITERS>
+
+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
+L<"Alternative Delimiters">, below.
+
+If you specify C<DELIMITERS> in the call to C<fill_in>, they override
+any delimiters you set when you created the template object with
+C<new>.
+
+=back
+
+=head1 Convenience Functions
+
+=head2 C<fill_this_in>
+
+The basic way to fill in a template is to create a template object and
+then call C<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. C<fill_this_in> accepts a
+string, which contains the template, and a list of options, which are
+passed to C<fill_in> as above. It constructs the template object for
+you, fills it in as specified, and returns the results. It returns
+C<undef> and sets C<$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 C<E<lt>E<lt>> notation.
+
+C<fill_this_in> is a deprecated feature. It is only here for
+backwards compatibility, and may be removed in some far-future version
+in C<Text::Template>. You should use C<fill_in_string> instead. It
+is described in the next section.
+
+=head2 C<fill_in_string>
+
+It is stupid that C<fill_this_in> is a class method. It should have
+been just an imported function, so that you could omit the
+C<Text::Template-E<gt>> in the example above. But I made the mistake
+four years ago and it is too late to change it.
+
+C<fill_in_string> is exactly like C<fill_this_in> except that it is
+not a method and you can omit the C<Text::Template-E<gt>> and just say
+
+ print fill_in_string(<<'EOM', ...);
+ Dear {$name},
+ ...
+ EOM
+
+To use C<fill_in_string>, you need to say
+
+ use Text::Template 'fill_in_string';
+
+at the top of your program. You should probably use
+C<fill_in_string> instead of C<fill_this_in>.
+
+=head2 C<fill_in_file>
+
+If you import C<fill_in_file>, you can say
+
+ $text = fill_in_file(filename, ...);
+
+The C<...> are passed to C<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 C<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 C<new> / C<fill_in> sequence instead.
+It will be a lot faster because it only has to read and parse the file
+once.
+
+=head2 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. VoilE<agrave>.
+
+If you don't want to use C<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 C<fill_in> call is package
+C<Q>. Then in the main program, write
+
+ *Q::include = \&Text::Template::_load_text;
+
+This imports the C<_load_text> function into package C<Q> with the
+name C<include>. From then on, any template that you fill in with
+package C<Q> can say
+
+ {include(filename)}
+
+to insert the text from the named file at that point. If you are
+using the C<HASH> option instead, just put C<include =E<gt>
+\&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 C<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.
+
+=head1 Miscellaneous
+
+=head2 C<my> variables
+
+People are frequently surprised when this doesn't work:
+
+ my $recipient = 'The King';
+ my $text = fill_in_file('formletter.tmpl');
+
+The text C<The King> doesn't get into the form letter. Why not?
+Because C<$recipient> is a C<my> variable, and the whole point of
+C<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 C<$recipient>.
+
+If that's not the behavior you want, don't use C<my>. C<my> 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 C<PACKAGE> option to C<fill_in>:
+
+ $Q::recipient = $recipient;
+ my $text = fill_in_file('formletter.tmpl', PACKAGE => 'Q');
+
+
+or pass the names and values in a hash with the C<HASH> option:
+
+ my $text = fill_in_file('formletter.tmpl', HASH => { recipient => $recipient });
+
+=head2 Security Matters
+
+All variables are evaluated in the package you specify with the
+C<PACKAGE> option of C<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 C<Safe>) 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 B<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 C<SAFE> option.
+
+A final warning: program fragments run a small risk of accidentally
+clobbering local variables in the C<fill_in> function itself. These
+variables all have names that begin with C<$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 C<$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.
+
+=head2 Alternative Delimiters
+
+Lorenzo Valdettaro pointed out that if you are using C<Text::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 C<new()> call or the C<fill_in()> call, you can specify
+an alternative set of delimiters with the C<DELIMITERS> option. For
+example, if you would like code fragments to be delimited by C<[@-->
+and C<--@]> instead of C<{> and C<}>, use
+
+ ... DELIMITERS => [ '[@--', '--@]' ], ...
+
+Note that these delimiters are I<literal strings>, not regexes. (I
+tried for regexes, but it complicates the lexical analysis too much.)
+Note also that C<DELIMITERS> 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 C<DELIMITERS> may speed up the
+parsing process by 20-25%. This shows that my original choice of C<{>
+and C<}> was very bad.
+
+=head2 C<PREPEND> feature and using C<strict> in templates
+
+Suppose you would like to use C<strict> 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 C<strict> 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 C<use strict> at the top of the second fragment,
+it was only active in the first fragment, and we didn't get any
+C<strict> checking in the second fragment. Then we mispelled C<$foo>
+and the error wasn't caught.
+
+C<Text::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 C<fill_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 C<fill_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 C<$boo> has not
+been declared. C<use strict> was implied, even though you did not
+write it explicitly, because the C<PREPEND> option added it for you
+automatically.
+
+There are two other ways to do this. At the time you create the
+template object with C<new>, you can also supply a C<PREPEND> option,
+in which case the statements will be prepended each time you fill in
+that template. If the C<fill_in> call has its own C<PREPEND> 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 C<fill_in> for I<any> template will
+attach the perl statements to the beginning of each program fragment,
+except where overridden by C<PREPEND> options to C<new> or C<fill_in>.
+
+=head2 Prepending in Derived Classes
+
+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 C<PREPEND> option in the C<fill_in> call, from
+the C<PREPEND> option in the C<new> call that created the template
+object, or from the argument of the C<always_prepend> call.
+C<Text::Template> looks for these three things in order and takes the
+first one that it finds.
+
+In a subclass of C<Text::Template>, this last possibility is
+ambiguous. Suppose C<S> is a subclass of C<Text::Template>. Should
+
+ Text::Template->always_prepend(...);
+
+affect objects in class C<Derived>? The answer is that you can have it
+either way.
+
+The C<always_prepend> value for C<Text::Template> is normally stored
+in a hash variable named C<%GLOBAL_PREPEND> under the key
+C<Text::Template>. When C<Text::Template> looks to see what text to
+prepend, it first looks in the template object itself, and if not, it
+looks in C<$GLOBAL_PREPEND{I<class>}> where I<class> is the class to
+which the template object belongs. If it doesn't find any value, it
+looks in C<$GLOBAL_PREPEND{'Text::Template'}>. This means that
+objects in class C<Derived> I<will> be affected by
+
+ Text::Template->always_prepend(...);
+
+I<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 C<Text::Template::always_prepend> calls by simply
+putting C<Derived-E<gt>always_prepend('')> at the top of your module.
+
+Of course, there is also a final escape hatch: Templates support a
+C<prepend_text> that is used to look up the appropriate text to be
+prepended at C<fill_in> time. Your derived class can override this
+method to get an arbitrary effect.
+
+=head2 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 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 C<DELIMITERS> option. However, if you can't do this for
+some reason, there are two easy workarounds:
+
+1. You can put C<\> in front of C<{>, C<}>, or C<\> 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, C<q{...}> is the same as C<'...'>.
+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.
+
+
+=head2 Shut Up!
+
+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 C<17> 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 C<{$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, C<$SILENTLY> has no value, so nothing will be
+interpolated. This is what is known as a `trick'.
+
+=head2 Compatibility
+
+Every effort has been made to make this module compatible with older
+versions. The only known exceptions follow:
+
+The output format of the default C<BROKEN> subroutine has changed
+twice, most recently between versions 1.31 and 1.40.
+
+Starting in version 1.10, the C<$OUT> variable is arrogated for a
+special meaning. If you had templates before version 1.10 that
+happened to use a variable named C<$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.
+
+=head2 Backslash Processing
+
+In C<Text::Template> beta versions, the backslash was special whenever
+it appeared before a brace or another backslash. That meant that
+while C<{"\n"}> did indeed generate a newline, C<{"\\"}> did not
+generate a backslash, because the code passed to Perl for evaluation
+was C<"\"> which is a syntax error. If you wanted a backslash, you
+would have had to write C<{"\\\\"}>.
+
+In C<Text::Template> versions 1.00 through 1.10, there was a bug:
+Backslash was special everywhere. In these versions, C<{"\n"}>
+generated the letter C<n>.
+
+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 C<{"\\\\"}> 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 I<unless> they occur
+as part of a sequence like C<\\\\\\{> or C<\\\\\\}>. In these
+contexts, they are special; C<\\> is replaced with C<\>, and C<\{> and
+C<\}> signal a literal brace.
+
+Examples:
+
+ \{ foo \}
+
+is I<not> evaluated, because the C<\> 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 C<Text::Template> thinks that the code ends at the first C<}>,
+and then gets upset when it sees the second one. To make this work
+correctly, use
+
+ { "foo\}" }
+
+This passes C<"foo}"> to Perl for evaluation. Note there's no C<\> in
+the evaluated code. If you really want a C<\> in the evaluated code,
+use
+
+ { "foo\\\}" }
+
+This passes C<"foo\}"> to Perl for evaluation.
+
+Starting with C<Text::Template> version 1.20, backslash processing is
+disabled if you use the C<DELIMITERS> option to specify alternative
+delimiter strings.
+
+=head2 A short note about C<$Text::Template::ERROR>
+
+In the past some people have fretted about `violating the package
+boundary' by examining a variable inside the C<Text::Template>
+package. Don't feel this way. C<$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
+C<TTerror> that returns the current value of the C<$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.
+
+=head2 Sticky Widgets in Template Files
+
+The C<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 C<CGI> functions from
+inside the template:
+
+ { $q->checkbox_group(NAME => 'toppings',
+ LINEBREAK => true,
+ COLUMNS => 3,
+ VALUES => \@toppings,
+ );
+ }
+
+=head2 Automatic preprocessing of program fragments
+
+It may be useful to preprocess the program fragments before they are
+evaluated. See C<Text::Template::Preprocess> for more details.
+
+=head2 Automatic postprocessing of template hunks
+
+It may be useful to process hunks of output before they are appended to
+the result text. For this, subclass and replace the C<append_text_to_result>
+method. It is passed a list of pairs with these entries:
+
+ handle - a filehandle to which to print the desired output
+ out - a ref to a string to which to append, to use if handle is not given
+ text - the text that will be appended
+ type - where the text came from: TEXT for literal text, PROG for code
+
+=head2 Author
+
+Mark Jason Dominus, Plover Systems
+
+Please send questions and other remarks about this software to
+C<mjd-perl-template+@plover.com>
+
+You can join a very low-volume (E<lt>10 messages per year) mailing
+list for announcements about this package. Send an empty note to
+C<mjd-perl-template-request@plover.com> to join.
+
+For updates, visit C<http://www.plover.com/~mjd/perl/Template/>.
+
+=head2 Support?
+
+This software is version 1.46. It may have bugs. Suggestions and bug
+reports are always welcome. Send them to
+C<mjd-perl-template+@plover.com>. (That is my address, not the address
+of the mailing list. The mailing list address is a secret.)
+
+=head1 LICENSE
+
+ Text::Template version 1.46
+ Copyright 2013 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.
+
+
+=head1 THANKS
+
+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 /
+AntE<oacute>nio AragE<atilde>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:
+
+=over 2
+
+=item Jonathan Roy
+
+for telling me how to do the C<Safe> support (I spent two years
+worrying about it, and then Jonathan pointed out that it was trivial.)
+
+=item 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
+C<$OUT> feature.
+
+=back
+
+=head2 Bugs and Caveats
+
+C<my> variables in C<fill_in> are still susceptible to being clobbered
+by template evaluation. They all begin with C<fi_>, so avoid those
+names in your templates.
+
+The line number information will be wrong if the template's lines are
+not terminated by C<"\n">. You should let me know if this is a
+problem. If you do, I will fix it.
+
+The C<$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.
+
+=cut
projects / openssl.git / commitdiff