| # -*- 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 itself. |
| # If in doubt, write to mjd-perl-template+@plover.com for a license. |
| # |
| |
| package Text::Template; |
| $Text::Template::VERSION = '1.56'; |
| # ABSTRACT: Expand template text with embedded Perl |
| |
| use strict; |
| use warnings; |
| |
| require 5.008; |
| |
| use base 'Exporter'; |
| |
| our @EXPORT_OK = qw(fill_in_file fill_in_string TTerror); |
| our $ERROR; |
| |
| my %GLOBAL_PREPEND = ('Text::Template' => ''); |
| |
| sub Version { |
| $Text::Template::VERSION; |
| } |
| |
| sub _param { |
| my ($k, %h) = @_; |
| |
| for my $kk ($k, "\u$k", "\U$k", "-$k", "-\u$k", "-\U$k") { |
| return $h{$kk} if exists $h{$kk}; |
| } |
| |
| return undef; |
| } |
| |
| 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, %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); |
| my $encoding = _param('encoding', %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, |
| ENCODING => $encoding, |
| (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 = shift; |
| |
| 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); |
| } |
| |
| if (defined $self->{ENCODING}) { |
| require Encode; |
| $data = Encode::decode($self->{ENCODING}, $data, &Encode::FB_CROAK); |
| } |
| |
| $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 = shift; |
| |
| $self->_acquire_data unless $self->{DATA_ACQUIRED}; |
| |
| return $self->{SOURCE}; |
| } |
| |
| sub set_source_data { |
| my ($self, $newdata, $type) = @_; |
| |
| $self->{SOURCE} = $newdata; |
| $self->{DATA_ACQUIRED} = 1; |
| $self->{TYPE} = $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 = shift; |
| |
| 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, %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_filename = _param('filename', %fi_a) || $fi_self->{FILENAME} || 'template'; |
| my $fi_strict = _param('strict', %fi_a); |
| my $fi_prepend = _param('prepend', %fi_a); |
| |
| my $fi_eval_package; |
| my $fi_scrub_package = 0; |
| |
| 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_varlist; |
| 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 |
| } |
| @fi_varlist = _install_hash($fi_varhash => $fi_install_package); |
| if ($fi_strict) { |
| $fi_prepend = "use vars qw(@fi_varlist);$fi_prepend" if @fi_varlist; |
| $fi_prepend = "use strict;$fi_prepend"; |
| } |
| } |
| |
| 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;\n;"; |
| my $fi_res; |
| my $fi_eval_err = ''; |
| |
| if ($fi_safe) { |
| no strict; |
| no warnings; |
| |
| $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 { |
| no strict; |
| no warnings; |
| |
| 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_r; # 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, $text) = splice @_, 0, 2; |
| |
| 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; |
| |
| open my $fh, '<', $fn or do { |
| $ERROR = "Couldn't open file $fn: $!"; |
| return undef; |
| }; |
| |
| local $/; |
| |
| <$fh>; |
| } |
| |
| 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}; |
| } |
| |
| %$hash = (); |
| |
| delete $Text::Template::{ $s . "::" }; |
| } |
| } |
| |
| # 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 @varlist; |
| |
| for my $hash (@$hashlist) { |
| for my $name (keys %$hash) { |
| my $val = $hash->{$name}; |
| |
| no strict 'refs'; |
| no warnings 'redefine'; |
| |
| local *SYM = *{"$ {dest}::$name"}; |
| |
| if (!defined $val) { |
| delete ${"$ {dest}::"}{$name}; |
| my $match = qr/^.\Q$name\E$/; |
| @varlist = grep { $_ !~ $match } @varlist; |
| } |
| elsif (ref $val) { |
| *SYM = $val; |
| push @varlist, do { |
| if (UNIVERSAL::isa($val, 'ARRAY')) { '@' } |
| elsif (UNIVERSAL::isa($val, 'HASH')) { '%' } |
| else { '$' } |
| } |
| . $name; |
| } |
| else { |
| *SYM = \$val; |
| push @varlist, '$' . $name; |
| } |
| } |
| } |
| |
| @varlist; |
| } |
| |
| sub TTerror { $ERROR } |
| |
| 1; |
| |
| __END__ |
| |
| =pod |
| |
| =encoding UTF-8 |
| |
| =head1 NAME |
| |
| Text::Template - Expand template text with embedded Perl |
| |
| =head1 VERSION |
| |
| version 1.56 |
| |
| =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 => 'Saruman', |
| fearsome => 'Sauron' }, |
| }; |
| $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. Smith, |
| |
| 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 => 'John', |
| lastname => 'Smith', |
| 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 evaluated 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 = Text::Template->new( 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: |
| |
| Text::Template->new( 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: |
| |
| Text::Template->new( 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: |
| |
| Text::Template->new( 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: |
| Text::Template->new ( 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<ENCODING> |
| |
| You may also add a C<ENCODING> option. If this option is present, and the |
| C<SOURCE> is a C<FILE>, then the data will be decoded from the given encoding |
| using the L<Encode> module. You can use any encoding that L<Encode> recognizes. |
| E.g.: |
| |
| Text::Template->new( |
| TYPE => 'FILE', |
| ENCODING => 'UTF-8', |
| SOURCE => 'xyz.tmpl'); |
| |
| =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<FILENAME>, 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<FILENAME> |
| |
| If you give C<fill_in> a C<FILENAME> option, then this is the file name that |
| you loaded the template source from. This only affects the error message that |
| is given for template errors. If you loaded the template from C<foo.txt> for |
| example, and pass C<foo.txt> as the C<FILENAME> parameter, errors will look |
| like C<... at foo.txt line N> rather than C<... at template line N>. |
| |
| Note that this does NOT have anything to do with loading a template from the |
| given filename. See C<fill_in_file()> for that. |
| |
| For example: |
| |
| my $template = Text::Template->new( |
| TYPE => 'string', |
| SOURCE => 'The value is {1/0}'); |
| |
| $template->fill_in(FILENAME => 'foo.txt') or die $Text::Template::ERROR; |
| |
| will die with an error that contains |
| |
| Illegal division by zero at at foo.txt line 1 |
| |
| =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 misspelled 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 three 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>. |
| |
| An alternative to adding "use strict;" to the PREPEND option, you can |
| pass STRICT => 1 to fill_in when also passing the HASH option. |
| |
| Suppose that the C<fill_in> call included both |
| |
| HASH => {$foo => ''} and |
| STRICT => 1 |
| |
| options, and that the template looked like this: |
| |
| { |
| $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<STRICT> option added it for you |
| automatically. Any variable referenced in the template that is not in the |
| C<HASH> option will be an error. |
| |
| =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 = Text::Template->new(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 = Text::Template->new(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 |
| |
| =head1 HISTORY |
| |
| Originally written by Mark Jason Dominus, Plover Systems (versions 0.01 - 1.46) |
| |
| Maintainership transferred to Michael Schout E<lt>mschout@cpan.orgE<gt> in version |
| 1.47 |
| |
| =head1 THANKS |
| |
| Many thanks to the following people for offering support, |
| encouragement, advice, bug reports, and all the other good stuff. |
| |
| =over 4 |
| |
| =item * |
| |
| Andrew G Wood |
| |
| =item * |
| |
| Andy Wardley |
| |
| =item * |
| |
| António Aragão |
| |
| =item * |
| |
| Archie Warnock |
| |
| =item * |
| |
| Bek Oberin |
| |
| =item * |
| |
| Bob Dougherty |
| |
| =item * |
| |
| Brian C. Shensky |
| |
| =item * |
| |
| Chris Nandor |
| |
| =item * |
| |
| Chris Wesley |
| |
| =item * |
| |
| Chris.Brezil |
| |
| =item * |
| |
| Daini Xie |
| |
| =item * |
| |
| Dan Franklin |
| |
| =item * |
| |
| Daniel LaLiberte |
| |
| =item * |
| |
| David H. Adler |
| |
| =item * |
| |
| David Marshall |
| |
| =item * |
| |
| Dennis Taylor |
| |
| =item * |
| |
| Donald L. Greer Jr. |
| |
| =item * |
| |
| Dr. Frank Bucolo |
| |
| =item * |
| |
| Fred Steinberg |
| |
| =item * |
| |
| Gene Damon |
| |
| =item * |
| |
| Hans Persson |
| |
| =item * |
| |
| Hans Stoop |
| |
| =item * |
| |
| Itamar Almeida de Carvalho |
| |
| =item * |
| |
| James H. Thompson |
| |
| =item * |
| |
| James Mastros |
| |
| =item * |
| |
| Jarko Hietaniemi |
| |
| =item * |
| |
| Jason Moore |
| |
| =item * |
| |
| Jennifer D. St Clair |
| |
| =item * |
| |
| Joel Appelbaum |
| |
| =item * |
| |
| Joel Meulenberg |
| |
| =item * |
| |
| Jonathan Roy |
| |
| =item * |
| |
| Joseph Cheek |
| |
| =item * |
| |
| Juan E. Camacho |
| |
| =item * |
| |
| Kevin Atteson |
| |
| =item * |
| |
| Kevin Madsen |
| |
| =item * |
| |
| Klaus Arnhold |
| |
| =item * |
| |
| Larry Virden |
| |
| =item * |
| |
| Lieven Tomme |
| |
| =item * |
| |
| Lorenzo Valdettaro |
| |
| =item * |
| |
| Marek Grac |
| |
| =item * |
| |
| Matt Womer |
| |
| =item * |
| |
| Matt X. Hunter |
| |
| =item * |
| |
| Michael G Schwern |
| |
| =item * |
| |
| Michael J. Suzio |
| |
| =item * |
| |
| Michaely Yeung |
| |
| =item * |
| |
| Michelangelo Grigni |
| |
| =item * |
| |
| Mike Brodhead |
| |
| =item * |
| |
| Niklas Skoglund |
| |
| =item * |
| |
| Randal L. Schwartz |
| |
| =item * |
| |
| Reuven M. Lerner |
| |
| =item * |
| |
| Robert M. Ioffe |
| |
| =item * |
| |
| Ron Pero |
| |
| =item * |
| |
| San Deng |
| |
| =item * |
| |
| Sean Roehnelt |
| |
| =item * |
| |
| Sergey Myasnikov |
| |
| =item * |
| |
| Shabbir J. Safdar |
| |
| =item * |
| |
| Shad Todd |
| |
| =item * |
| |
| Steve Palincsar |
| |
| =item * |
| |
| Tim Bunce |
| |
| =item * |
| |
| Todd A. Green |
| |
| =item * |
| |
| Tom Brown |
| |
| =item * |
| |
| Tom Henry |
| |
| =item * |
| |
| Tom Snee |
| |
| =item * |
| |
| Trip Lilley |
| |
| =item * |
| |
| Uwe Schneider |
| |
| =item * |
| |
| Val Luck |
| |
| =item * |
| |
| Yannis Livassof |
| |
| =item * |
| |
| Yonat Sharon |
| |
| =item * |
| |
| Zac Hansen |
| |
| =item * |
| |
| gary at dls.net |
| |
| =back |
| |
| 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. |
| |
| =head1 SOURCE |
| |
| The development version is on github at L<https://https://github.com/mschout/perl-text-template> |
| and may be cloned from L<git://https://github.com/mschout/perl-text-template.git> |
| |
| =head1 BUGS |
| |
| Please report any bugs or feature requests on the bugtracker website |
| L<https://github.com/mschout/perl-text-template/issues> |
| |
| When submitting a bug or request, please include a test-file or a |
| patch to an existing test-file that illustrates the bug or desired |
| feature. |
| |
| =head1 AUTHOR |
| |
| Michael Schout <mschout@cpan.org> |
| |
| =head1 COPYRIGHT AND LICENSE |
| |
| This software is copyright (c) 2013 by Mark Jason Dominus <mjd@cpan.org>. |
| |
| This is free software; you can redistribute it and/or modify it under |
| the same terms as the Perl 5 programming language system itself. |
| |
| =cut |