The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.
#========================================================================
#
# Changes 
#
# DESCRIPTION
#   Revision history for the Template Toolkit version 2.00, detailing
#   significant changes between versions, most recent first.  Some 
#   way down the file you'll find a section detailing major changes from 
#   version 1.* to 2.* and a list of "Gotchas!" that you might have to 
#   look out for when upgrading between major versions.
#
# AUTHOR
#   Andy Wardley   <abw@kfs.org>
#
#------------------------------------------------------------------------
# $Id: Changes,v 2.6 2000/09/14 12:47:20 abw Exp $
#========================================================================

#------------------------------------------------------------------------
# Version 2.00 beta 5  14th September 2000
#------------------------------------------------------------------------

* Added define_filter($name, \&filter, $is_dynamic) method to
  Template::Context to allow additional filters to be defined at any
  time.  Arguments are as per the FILTERS configuration option.
  These filters persist for the lifetime of the processor.

* Changed the Template::Context filter() method to accept a code 
  reference as the filter name and use it as the filter sub.  This 
  allows filters to be bound to template variables which are then 
  used as:

    [% FILTER $myfilter %]

  There is one catch, however.  TT will automatically call a subroutine
  bound to a variable when evaluated.  Thus you must wrap your filter
  sub in another sub: $stash->set('foo', sub { \&myfilter }); or bless
  it into some class (any class) to fool TT into thinking it's not a 
  subroutine ref: $stash->set('bar', bless \&myfilter, 'any_old_name');

* Updated documentation for FILTER directive and FILTERS option to 
  reflect the above changes.

* Fixed Template::Document to run cleanly with taint checking enabled.
  Unfortunately, this has been achieved by blindly untainting the
  generated template Perl code before calling eval().  Given that
  we're reading template source from external files, I don't think
  there's any way to do reliable taint check anyway.  But thankfully
  we can trust the parser to generate "safe" code unless EVAL_PERL is
  enabled in which case all bets are off anyway.

* Updated XML::DOM plugin to include changes made by Thierry-Michel 
  Barral to accept configuration options for XML::Parser.

* Fixed a bug in the Table plugin which caused the first item to be
  repeated n times when n items was less than a specified number of
  columns.  Thanks to Andrew Williams for finding and fixing this
  bug.

* The Template::Tutorial document really is included in the
  distribution this time.  Honest.


#------------------------------------------------------------------------
# Version 2.00 beta 4  12th September 2000
#------------------------------------------------------------------------

* Added the PROCESS config option which allows a template or templates
  to be specified which is/are processed instead of the template
  passed as an argument to the Template process() method.  The
  original template is available as the 'template' variable and can be
  processed by calling INCLUDE or PROCESS as [% INCLUDE $template %].

* Changed what was the CASE option to now be enabled by default, and
  then changed the name of the option to ANYCASE to make it more
  obvious as to what it did.  You must now specify directive keywords
  (INCLUDE, FOREACH, IF, etc) in UPPER CASE only, or enable the
  ANYCASE option to revert to the previous behaviour of recognising
  keywords in any case.  With the increase in reserved words in
  version 2, there is more chance of collision with variable names.
  It's a real pain not being able to have a variable called 'next', an
  exception called 'perl', etc., because there's a reserved word of
  the same name.  Thus, keywords are now UPPER CASE only by default,
  neatly side-stepping the problem.

* Changed the PERL directive so that output is generated by calling
  print() instead of using the final value in the block.  Implemented
  by tying STDOUT to an output buffer based on a patch sent in by
  Chuck Adams.

    new:                      old:
      [% PERL %]                [% PERL %]
         print "foo\n";            my $output = "foo\n";
         ...                       ...
         print "bar\n";            $output .= "bar\n";
      [% END %]			   $output;
                                [% END %]

* The IMPORT directive and magical IMPORT variable have been replaced 
  with a general purpose virtual hash method, import().

    [% hash1.import(hash2) %]   # was "hash1.IMPORT = hash2"
    [% import(hash1) %]	        # was "IMPORT hash1" or "IMPORT = hash1"

* Modified the Template::Filters provider to examine the FILTERS
  package hash reference (changed name from STD_FILTERS) each time a
  filter is requested rather than copying them at construction time.
  This allows new filters to be added on-the-fly.  See t/filter.t for
  examples and Template::Filters for more info.
  
* Added the 'nsort' list method which sorts items using a numerical 
  value sort rather than an alpha sort. 

    [% data = [ 1, 5, 10, 11 ] %]
    [% data.sort.join(', ')  %]     # 1, 10, 11, 5
    [% data.nsort.join(', ') %]     # 1, 5, 10, 11  

* Added 'div' operator to provider integer division (e.g. 'a div b' =>
  'int(a / b)' and 'mod' which is identical to '%' but added for backwards
  compatibility with V1.

* Changed the (undocumented) FORNEXT directive to NEXT and documented it.

* Fixed a bug in the persistant caching mechanism in Template::Provider
  which was failing to write compiled template files for source templates
  specifed in the form [% INCLUDE foo/bar %].  Intermediate directories 
  (like 'foo' in this example) weren't being created and the disk write 
  was failing.  Thanks to Simon Matthews for identifying this problem.

* Fixed an obscure bug in the Template::Stash which was ignoring the
  last element in a compound variable when followed by an empty 
  argument list.  e.g. [% cgi.param() %] would be treated as [% cgi %].
  Also fixed the DEBUG option so that undefined variables cause 'undef'
  exceptions to be raised.  Thanks to Jonas Liljegren for reporting the 
  problems.

* Added the reference operator, '\' which allows a "reference" to 
  another variable to be taken.  The implementation creates a closure
  around the referenced variable which, when called, will return the 
  actual variable value.  It is really a form of lazy evaluation, rather
  than genuine reference taking, but it looks and smells almost the same.
  Primarily, it is useful for allowing sub-routine references to be 
  passed to another sub-routine.  This is currently undocumented 
  because I'm not sure about the validity of adding it, but See t/refs.t 
  for examples for now.

* Changed parser to automatically unescape any escaped characters in 
  double quoted strings except for \n and \$.  This permits strings to
  be constructed that include tag characters.  e.g.

    [% directive = "[\% INSERT thing %\]" %]

* Fixed a bug in the use of the 'component' variable when the current
  component is a sub-routine rather than a Template::Document.

* Added the '--define var=val' option to tpage to allow template 
  variables to be defined from the command line.  Added support to
  ttree for various new Template configuration options.

* Added $Template::Test::PRESERVE package variable which can be set to 
  prevent newlines in test output from being automatically mangled to
  literal '\n'.

* Completed and corrected all knows bugs in the documentation which
  now weighs in at around 100 pages for the Template.pm module alone.
  The POD documentation should now be installed by default.  The
  Template::Tutorial document is once again included in the
  distribution.


#------------------------------------------------------------------------
# Version 2.00 beta 3  10th August 2000
#------------------------------------------------------------------------

* Added the WRAPPER directive to include another template, passing the 
  enclosing block as the 'content' variable.  e.g.

  somefile:                    mytable:
    [% WRAPPER mytable %]        <table>
       blah blah blah            [% content %]
    [% END %]                    </table>

  This is equivalent to:

    [% content = BLOCK %]
       blah blah blah
    [% END %]
    [% INCLUDE mytable %]

* Added the [% INSERT file %] directive to insert the contents of a disk
  file without processing any of the content.  Looks for the file in the
  INCLUDE_PATH and honours the ABSOLUTE and RELATIVE flags.  Added the
  insert($file) method to Template::Context which calls the new 
  load($file) method in Template::Provider which loads the file text
  without compiling it.

* Added the DEFAULT configuration option which allows you to specify a 
  default template which should be used whenever a named template 
  cannot be found.  This is ignored for templates specified with absolute
  or relative filenames, or as references to an input filehandle or text.

* Added a FORNEXT directive to step on to the next iteration of a
  FOREACH loop, as suggested/requested by Jo Ellen Wisnosky.  I chose
  FORNEXT rather than simply NEXT because 'next' is a very common
  variable name but I'm open to better suggestions.  Perhaps CASE
  should be set by default to prevent variable conflict?  This might
  change.

* Reorganised the Template::Filters modules and changed the calling 
  convention for requesting filters via the fetch() method.  This now
  expects a reference to the calling Template::Context object as the
  third parameter (after filter name and reference to a list of arguments).
  Static filter sub-routines are returned as before and the context has
  no effect.  Dynamic filter factories (denoted by a $is_dynamic flag
  in the FILTER_FACTORY table) are called to create a filter sub-routine
  (closure) for each request.  The context is now passed as the first
  parameter, followed by the expansion of any arguments.  Filter 
  factories should return a sub-routine or (undef, $error) on error.

* Added several new filters:
  - 'stderr' prints the output to STDERR (i.e. for generating output 
    in the Apache logfile, for example).  e.g. [% message | stderr %]

  - 'file' is the equivalent of the version 1 redirect() filter which 
    writes the output to a new file, relative to OUTPUT_PATH.  Throws
    a 'file' exception if OUTPUT_PATH is not set.  There should perhaps 
    be some other way to disable this without relying on OUTPUT_PATH.

  - 'eval' evaluates the input as a template and processes it.  Proposed
    by Simon Matthews for times when you might be returning templates 
    fragments from a database, for example.  e.g. [% dirtext | eval %]

  - 'evalperl' evaluate the input as Perl code, as suggested by Jonas
    Liligren. Requires the EVAL_PERL option to be set and will throw a 
    'perl' error if not (see later item).  e.g. [% perlcode | evalperl %]

* Fixed a bug in Template::Provider which was mangling the metadata items
  for the template name and modification time.  The [% template.name %] 
  and [% template.modtime %] variables now work as expected.

* Added 'component' variable, similar to 'template', but which references 
  the current template component file or block, rather than the top-level 
  template.  Of course, these may be one and the same if you're not nesting
  any templates.

* Template::Provider now reports errors raised when re-compiling 
  modified templates rather than ignoring them, thanks to a patch from
  Perrin Harkins.

* Fixed Template::Context to recognise the RECURSION option once more,
  thanks to a patch from Rafael Kitover.

* Overloaded "" stringification of Template::Exception to call as_string(),
  again thanks to Rafael.  In a catch block you can now simply say 
  [% error %] as well as the more explicit  [% error.type %] and/or 
  [% error.info %].

* Changed Template module (via Template::Service) to return the
  exception raised rather than a pre-stringified form.  This allows
  you to test the type() and/or info() if you want, or just print it
  and rely on the automatic stringification mentioned above to format
  it as expected.  Note that the top-level process($file) method
  returns a string rather than an exception if $file can't be found.
  This is a bug, or a possible "gotcha" at the very least, and should
  get fixed some time soon.  For now, test that the error is a
  reference before attempting to call info() or type().

* Fixed a bug preventing literal newlines from being used in strings.
  Thanks to Simon Matthews for bringing it to my attention by calling 
  my hotel room at the Perl Conference and saying "Hello?  Is that the 
  Template Toolkit Helpdesk?  I have a bug to report..."  :-) 
  (I fixed it on his laptop a few minutes later - good service, eh?)

* Changed Template::Parser to not compile PERL or RAWPERL blocks if
  EVAL_PERL is not set.  Previously they were compiled but switched out
  at runtime.  This was erroneous as rogue BEGIN { } blocks could still
  be executed, as noted by Randal Schwartz.  Any PERL or RAWPERL blocks
  encountered when EVAL_PERL is disabled will now cause a 'perl' exception
  to be thrown. 

* Added a define_block($name, $block) option to Template::Context to 
  add a definition to the local BLOCKS cache.  $block can be a reference
  to a template sub-routine or Template::Document object or template 
  text which is first compiled.

* Any other errors thrown in a PERL blocks (assuming EVAL_PERL set)
  are now left unchanged.  Previously, these were converted to 'perl'
  exceptions which prevented exceptions of other kinds being throw
  from within Perl code.

* Applied a patch from Chris Dean to fix a bug in the list 'sort' 
  method which was converting a single element list into a hash.  The
  sort now does nothing unless there's > 1 elements in the list.

* Changed Template::Stash set() method to append the assigned value to
  the end of any arguments specified, rather than prepending it to the 
  front.  e.g. The foo() method called by [% myobj.foo(x, y) = z %] now
  receives arguments as foo(x, y, z) instead of foo(z, x, y).

* Changed Template::Base::error() to accept a reference (e.g. exception)
  as the first parameter.  In this case, no attempt is made to 
  concatenate (and thereby stringify) the arguments.

* Added a direct stash() accessor method to Template::Context rather 
  than relying on the slower AUTOLOAD method.

* Added an iterator() method to Template::Config to require
  Template::Iterator and instantiate an iterator, and changed
  generated code for FOREACH to call this factory method.  This fixes
  a bug with pre-compiled (i.e persistant) templates which were
  failing if Template::Iterator wasn't already loaded.  Thanks to Doug
  Steinwand, Rafael Kitover and Jonas Lilegren who all identified the
  problem and hounded me until I fixed it.  :-)
 
* Fixed a problem with persistant templates not being reloaded due to 
  the %INC hash.  This caused 1 to be returned from require() instead 
  of the compiled template.

* Added ABSOLUTE and RELATIVE options to tpage by default.

* Applied various documentation and test patches from Leon Brocard.
  Fixed docs to quote dotted exception types to prevent string
  concatenation, as noted by Randal Schwartz.  Generally added a 
  whole lot more documentation.

#------------------------------------------------------------------------
# Version 2.00 beta 2   14th July 2000
#------------------------------------------------------------------------

* Added COMPILE_DIR option.  This allows you to specify a separate 
  directory in which compiled templates should be written.  The COMPILE_DIR
  is used as a root directory and each of the INCLUDE_PATH elements is 
  created below that point.  e.g. the following options

    COMPILE_DIR  => '/tmp/ttcache', 
    INCLUDE_PATH => '/user/foo/bar:/usr/share/templates',

  would create the following cache directories:

    /tmp/ttcache/user/foo/bar
    /tmp/ttcache/usr/share/templates

  Templates originating from source files in the INCLUDE_PATH are thus 
  written in their compiled form (i.e. Perl) to the relevant COMPILE_DIR
  directory.  The COMPILE_EXT option may also be used in conjunction with
  COMPILE_DIR to append a filename extension to all compiled files.
  
* Fixed memory leaks caused by the huge circular reference that is the 
  Template::Provider's linked list of cache slots.  Added a DESTROY method 
  which walks the list and explicitly breaks the chains (i.e. the NEXT/PREV
  links), thus allowing the compiled Template::Document objects to be 
  correctly destroyed and their memory repooled.  Thanks to Perrin Harkins
  for spotting the problem.

* Added a work-around in Template::Stash _dotop() to the problem of the 
  CGI module denying membership of the UNIVERSAL class on subsequent calls
  to UNIVERSAL::isa($cgi, 'UNIVERSAL').  It works correctly the first time,
  but returns false for all subsequent calls.  Changed this generic
  "is-an-object" test to UNIVERSAL::can($cgi, 'can') on the suggestion
  of Drew Taylor who identified the problem.

* Added t/macro.t to test MACRO directive, t/compile4.t and t/compile5.t
  to test the COMPILE_DIR option.

* More complete documentation, but not yet fully complete.


#------------------------------------------------------------------------
# Version 2.00 beta 1   10th July 2000
#------------------------------------------------------------------------

* Template::Context include()/process() now works with raw CODE refs.

* Template.pm now prefixes OUTPUT with the OUTPUT_PATH when OUTPUT
  is a file name.

* Cleaned up Template::Iterator.  Now derived from Template::Base.
  Removed ACTION and ORDER now that they are supported as list pseudo
  methods in the Stash LIST_OPS.

* Fixed bug in Provider preventing updated files from being automatically
  reloaded.  Thanks to Perrin Harkins who provided the patch.

* Fixed bug in Template::Plugin::Datafile which was preventing a comment
  from being placed on the first line of the file.

* Fixed bug in parse grammer preventing commas in a META list

* Added cache persistance by writing real Perl to file (rather than
  the previous Data::Dumper dump of the opcode tree).  Had to
  re-organise a bunch of code around the parser/provider/document.  
  Activated by COMPILE_EXT configuration item.

* Added a work-around in Template::Stash to the problem of CGI disclaiming
  membership of the UNIVERSAL class after the first method call.

* Added AUTO_RESET option which is enabled by default.  Disable this 
  (AUTO_RESET => 0) for block persistance across service invocations.

* Fixed \@ quoting (and others) in Directive thanks to Perrin Harkins 
  who reported the bug and Chuck Adams who provided a patch.

* Added Date plugin and test, as provided by Thierry-Michel Barral.

* Integrated changes to Template::Test from version 1.07 and beyond.  Now 
  supports -- process -- option in expect, mainly for use of t/date.t et al.

* Integrated new upper and lower filters from 1.08, and '|' alias for FILTER
  from 1.07.

* Added new directive.t test to test chomping and comments.

* BLOCKS can now be defined as template text which gets automatically 
  compiled into a Template::Document object.

* Integrated XML plugins and tests from version 1.07

* Fixed TRIM option to work with all BLOCKs and templates.  Moved TRIMing
  operation into context process() and include() methods.  Also changed
  service to call $context->process($template) rather than call the sub/
  doc itself, thus ensuring that the output can get TRIMmed.

* Updated Template::Plugin.pm

* Added '--define' option to ttree.

* Integrated various plugins and filters from v1.07

* Moved Template::Utils::output into Template.pm?) and got rid of
  Template::Utils altogether.

* Fixed bug in Context filter() provider method which wasn't caching 
  filters with args.

* [% CASE DEFAULT %] is now an alias for [% CASE %] (the default case),
  in consistency with [% CATCH DEFAULT %] / [% CATCH %]


#------------------------------------------------------------------------
# Version 2.00 alpha 1
#------------------------------------------------------------------------

* first public alpha release of Version 2.00
 


#========================================================================
#                           VERSION 2.00
#------------------------------------------------------------------------
# The following list outlines the major differences between version 1.*
# and version 2.00 of the Template Toolkit. 
#========================================================================

New Language Features
---------------------

* New SWITCH / CASE statement.  SWITCH takes an expression, CASE takes
  a value or list of values to match.  CASE may also be left blank or
  written as [% CASE default %] to specify a default match.  Only one
  CASE matches, there is no drop-through between CASE statements.
  
    [% SWITCH myvar %]
    [% CASE value1 %]
       ...
    [% CASE [ value2 value3 ] %]   # multiple values to match
       ...
    [% CASE myhash.keys %]         # ditto
       ...
    [% CASE %]                     # default, or [% CASE default %]
       ...
    [% END %]
  
* New TRY / CATCH / FINAL construct for fully functional, nested
  exception handling.  The block following the TRY is executed and
  output if no exceptions are throw.  Otherwise, the relevant CATCH
  block is executed.  CATCH types are hierarchical (e.g 'foo' catches
  'foo.bar') or the CATCH type may be left blank or specified as [%
  CATCH default %] to provide a default handler.  The contents of a
  FINAL block, if specified, will be processed last of all, regardless
  of the result (except an uncaught exception which is throw upwards
  to any enclosing TRY block).
  
    [% TRY %]
       ...blah...blah...
       [% CALL somecode %]	  # may throw an exception
       ...etc...
       [% INCLUDE someblock %]    # may have a [% THROW ... %] directive
       ...and so on...
    [% CATCH file %]		  # catch system-generated 'file' exception 
       ...
    [% CATCH DBI %]		  # catch 'DBI' or 'DBI.*'
       ...
    [% CATCH %]	                  # catch anything else
       ...
    [% FINAL %]		          # optional
       All done!
    [% END %]

* New CLEAR directive to clear the current output buffer.  This is typically 
  used in a CATCH block to clear the output of a failed TRY block.  Any output
  generated in a TRY block up to the point that an exception was thrown will
  be output by default.  The [% CLEAR %] directive in a catch block clears
  this output from the TRY block.

    [% TRY %]
       blah blah blah, this is the current output block
       [% THROW some.error 'Danger Will Robinson!' %]
       not reached...
    [% CATCH %]
       [% # at this point, the output block contains the 'blah blah...' line
          # up to the point where the THROW occured, but we don't want it
          CLEAR
       %]
       Here we can add some more text if we want...
    [% END %]

  In general, the CLEAR directive clears the current output from the
  template or enclosing block.

* New META directive allowing you to define metadata items for your
  templates.  These are attached to the compiled template and wrapped
  up as a Template::Document object.  The 'template' variable is a
  reference to the current parent document and metadata items may be
  accessed directly.  Of particular note is the fact that the
  'template' variable is correctly defined for all PRE_PROCESS and
  POST_PROCESS headers.  Thus, your headers and footers can access
  items from the main template (e.g. title, author, section, keywords,
  flags, etc) and display them or act accordingly.
  
  mytemplate:
    [% META 
       title     = 'This is a Test'
       author    = 'Andy Wardley'
       copyright = "2000, Andy Wardley" 
    %]
  
    <h1>[% template.title %]</h1>
    blah blah
  
  header:   (a PRE_PROCESS template)
    <html>
    <head><title>[% template.title %]</title></head>
    <body>
  
  footer:  (a POST_PROCESS template)
    <hr>
    &copy; Copyright [% template.copyright or '2000, MyCompany' %]

* New RAWPERL ... END block directive allows you to write raw Perl
  code which is integrated intact and unsullied into the destination
  template sub-routine.  The existing PERL ... END directive continues
  to be supported, offering runtime evaluation of a block which may
  contain other template directives, etc, which are first evaluated
  (e.g. PERL...END processes the block and filters the output into
  Perl evaluation at runtime).

* New INSERT directive which inserts the contents of a file without 
  processing it.

* New WRAPPER directive which processes the following block into the
  'content' variable and then INCLUDEs the named file.

    [% WRAPPER table %]
       blah blah blah
    [% END %]

    [% BLOCK table %]
    <table>
    [% content %]
    </table>
    [% END %]

* Comments now only extend to the end of the current line.

    [% # this is a comment
       a = 10
       # so is this
       b = 20
    %]

  Placing the '#' character immediately inside the directive will comment
  out the entire directive

    [%# entire directive
        is ignored
    %]

* The TAGS directive can now be used to switch tag styles by name.
  Several new tag styles are defined (e.g. html, asp, php, mason).

    [% TAGS html %]
    <!-- INCLUDE header -->

* The output from any directive or block can now be captured and assigned to 
  a variable.

    [% htext = INCLUDE header %]
    [% btext = BLOCK %]
       blah blah
       [% x %] [% y %] [% z %]
    [% END %]
  
    # you can even assign the output of loops, conditions, etc.
    [% numbers = FOREACH n = [2, 3, 5, 7, 11, 13] %]
       blah blah [% n %]
    [% END %]

* The handling of complex expressions has been improved, permitting
  basic directives to contain logical shortcut operators, etc.  All 
  binary operators now have the same precedence rules as Perl.

    [% foo or bar %]             # GET foo, or bar if foo is false (0/undef)
    [% CALL func1 and func2 %]   # func2 only called if func1 returns true
    [% name = user.id or cgi.param('id') %].

* A new "x ? y : z" operation is provided as a shorthand for
  "if x then y else z"

    [% foo = bar ? baz : qux %]

* A leading '$' on a variable is now used to indicate pre-interpolation
  of that element.  This simplifies the syntax and makes it consistent
  with double-quoted string interpolation and text block interpolation
  via the INTERPOLATE flag.  If you've been relying on the version 1
  "feature" that ignores the leading '$' then you'll need to change your
  templates to remove the '$' characters (except where you really want 
  them) or set the V1DOLLAR flag to 1 to revert to the version 1 
  behaviour.  See the 'Gotchas' section below for more details.

    # version 1
    [% hash.${key} %]  [% hash.${complex.key} %]

    # version 2
    [% hash.$key %]    [% hash.${complex.key} %]

* Various new pseudo-methods have been added for inspecting and manipulating
  data.  The full list now looks something like this:

      [% var.defined %]                    # variable is defined
      [% var.length %]                     # length of string
      [% var.split(delimiter, limit) %]    # split string as Perl does

      [% hash.keys %]                      # return list of hash keys
      [% hash.values %]                    # ditto hash values

      [% list.size %]                      # number of items in list
      [% list.max %]                       # last item number (size - 1)
      [% list.first %]                     # first item    
      [% list.last %]                      # last item
      [% list.reverse %]                   # list in reverse order
      [% list.sort(field) %]               # list in sorted order
      [% list.join(joint) %]               # join items into single string


Templates Compiled to Perl Code
-------------------------------

Templates are now compiled to Perl code, with credit and respect due
to Doug Steinwand for providing an implementation around which the
new parser was built.  This brings a number of important benefits:

* Speed and Memory Efficiency

  Version 1 used a list of opcodes to represent directives and
  lower-level operations.  These were evaluated by the hideously
  contrived, and darkly sinister Template::Context::_evaluate()
  method.  In version 2, all templates are parsed and rebuilt as Perl
  code.  This is then evaluated and stored as a reference to a Perl
  sub-routine which can then be executed and re-executed significantly
  faster and with far less memory overhead.

* Persistance.

  Once a template has been compiled to Perl code it can be saved to
  disk as a "compiled template" by defining the COMPILE_EXT option.
  This allows you to specify a filename extension (e.g. '.ttc') which
  is added to the template filename and used to create a new file
  containg the Perl code.  Next time you use the template, even if
  you've shut down your program/server/computer in the mean time, the
  compiled template is there in a file as Perl code and is simply
  require()d and executed.  It all happens significantly faster
  because there's no Template::Parser to run.  In fact, if all your
  templates are "compiled" on disk then the Template::Parser and
  Template::Grammar modules won't even be loaded, further reducing
  startup time and memory consumption (the grammar file, in particular
  is rather large).  The Template::Provider module handles the
  loading, caching and persistance of templates, and will examine file
  timestamps and re-compiled modified templates as required.

* Flexibility.  

  Because "compiled templates" are now nothing more than Perl
  sub-routines, you can use anyone or anything to generate them and
  run them all under the same roof.  Different parser back-ends can
  generate Perl code optimised for speed or functionality, for
  example.  Or different parsers can compile different template
  languages (PHP, ASP, Mason, roll-your-own, etc.) and run them
  alongside regular templates.  Or if you don't trust a parser, you
  can even write your own Perl code and have your templates execute as
  fast as the code you can write.


Configuration Options
---------------------

* Template blocks may be pre-defined using the new BLOCKS option.  These
  may be specified as template text or as references to sub-routines or
  Template::Document objects.

    my $template = Template->new({
	BLOCKS => {
	    header => '<html><head><title>[% title %]</title></head><body>',
	    footer => '</body></html>',
	    funky  => sub { blah_blah($blah); return $some_text },
	}
    });

* Automatic error handling can be provided with the ERROR option.  This
  allows you to specify a single template or hash array of templates which
  should be used in the case of an uncaught exception being raised in the
  a template.  In other words, if something in one of your templates
  throws a 'dbi' error then you can define an ERROR template to catch
  this.  The original template output is discarded and the ERROR template
  processed in its place.  PRE_PROCESS and POST_PROCESS templates (e.g.
  header and footers) are left intact.  This provides a particularly 
  useful high-level error handling abstraction where you simply create
  templates to handle particular exceptions and provide the mapping 
  through the ERROR hash.

    my $template = Template->new({
	ERROR => {
	    dbi        => 'error/database.html',   # DBI error
	    'user.pwd' => 'error/badpasswd.html',  # invalid user password
	    user       => 'user/index.html',	   # general 'user' handler
	    default    => 'error/error.html',      # default error template
	}
    });

* The INCLUDE_PATH is now fully dynamic and can be changed at any time.
  The new Template::Provider which manages the loading of template files
  will correctly adapt to chahges in the INCLUDE_PATH and act accordingly.

* The LOAD_TEMPLATES option allows you to specify a list of one or more
  Template::Provider object which will take responsibility for loading
  templates.  Each provider can have it's own INCLUDE_PATH, caching
  options (e.g CACHE_SIZE) and so on.  You can sub-class the
  Template::Provider module to allow templates to be loaded from a
  database, for example, and then define your new provider in the
  LOAD_TEMPLATES list.  The providers are queried in order as a "Chain 
  of Responsiblity".  Each may return a compiled template, raise an
  error, or decline to serve the template and pass control onto the
  next provider in line.

* The CACHE_SIZE option defines a maximum number of templates that will
  be cached by the provider.  It is undefined by default, causing all
  templates to be cached.  A value of 0 disables caching altogether while
  a positive integer defines a maximum limit.  The cache (now built into
  Template::Provider) is much smarter and will automatically reload and
  compile modified source templates.

* The Template::Provider cache can write compiled templates (e.g. Perl code)
  to disk to create a persistant cache.  The COMPILE_EXT may be used to 
  specify a filename extension (e.g. '.ttc') which is used to create
  compiled template files.  These compiled template files 
  can then be reloaded on subsequent invocations using via Perl's 
  require() (which is about as fast as it can get).  The Template::Parser 
  and Template::Grammar modules are loaded on demand, so if all templates
  have been pre-compiled then the modules don't get loaded at all.  This 
  is a big win, given that Template::Grammar is the biggy.

* The ABSOLUTE and RELATIVE options are now used to enable the loading of
  template files (via INCLUDE or PROCESS) that are specifies with absolute
  (e.g. /tmp/somefile) or relative (e.g. ../tmp/another) filenames.  Both
  are disabled by default.

* The LOAD_PLUGINS option is similar to LOAD_TEMPLATES but allows you
  to specify one or more plugin providers.  These take responsibility
  for loading and instantiating plugins.  The Template::Plugins module
  is the default provider and multiplexes requests out to other
  Template::Plugin::* plugin modules.  Loading of plugins has been
  simplified and improved in general The PLUGINS option can be used to
  map plugin names to specific modules and PLUGIN_BASE can map plugins
  into particular namespaces.  The LOAD_PERL option can be used to
  load (almost) any regular Perl module and use it as a plugin.

* The LOAD_FILTERS option is similar to LOAD_TEMPLATES and LOAD_PLUGINS, 
  allowing one or more custom providers to be specified for providing
  filters.  The Template::Filters module is the default provider here.

* The TOLERANT option can be used to tailor the behaviour of providers
  (e.g. Template::Provider, Template::Plugins, Template::Filters) when
  they encounter an error.  By default, providers are not TOLERANT (0)
  and will report all failures as errors.  When TOLERANT is set to 1,
  they will ignore errors and return STATUS_DECLINED to give the next
  provider a chance to deliver a valid resource.

* The INTERPOLATE option is now automatically disabled within PERL and 
  RAWPERL blocks to prevent Perl $variables from being interpreted as 
  template variables.

    # INTERPOLATE = 1
    This $var will get interpolated...
    [% PERL %]
       # but these won't
       my $foo = 'some value';
       my $bar = 'another value';
       # etc...
    [% END %]
    now we're interpolating variables again, like $var

* Added the TRIM option to automatically removed leading and trailing 
  whitespace from the output of templates and BLOCKs.

Other Enhancements and Internal Features
----------------------------------------

* Templates (i.e. sub-routines) now return their generated output,
  rather than sending it to $context->output().  This speeds things 
  up and makes the code simpler, as well as allowing greater 
  flexibility in how template sub-routines can work.

* Exceptions are now raised via Perl's die() and caught by an
  enclosing eval { } block.  Again, this simplifies the code generated
  and improves runtime efficiency.  The [% RETURN %] and [% STOP %]
  directives are now implemented as special case exceptions which are
  caught in the appropriate place and handled accordingly.

* Local named BLOCK definitions are better behaved and don't permanently
  mask any real files.  BLOCK definitions remain local to the template in 
  which they're defined, although they can be accessed from templates 
  INCLUDEd or PROCESSed from within.  The PROCESS directive will export 
  defined BLOCKs to the caller (as with variables) whereas INCLUDE will
  keep them "private".

* The Template::Stash object now encapsulates all the magical variable
  resolution code.  Both simple and compound variables can be accessed
  or updated using the get() and set() methods, with all variable binding
  magic happening automatically.

* The Template::Context object is now greatly simplified.  This acts
  as a general interface to the Template Toolkit functionality, being
  a collection of the various other modules that actually implement
  the functionality (e.g. Template::Stash, Template::Provider,
  Template::Document, Template::Plugins, etc.)

* The Template::Provider object provides a general facility for
  retrieving templates from disk (or other source), and if necessary
  compiling via a call to a Template::Parser helper object.  Multiple
  Template::Provider objects may be chained together, each with their
  own caching options, and so on.

* The Template::Parser object now compiles template text into Perl
  code and then evaluates it into a sub-routine reference using Perl's
  eval().  This is then wrapped up into a Template::Document object,
  including any metadata items and/or additional named BLOCKs defined
  in the input template.

* The Template::Document object is a thin wrapper around a compiled
  template sub-routine.  It provides a process() method for processing
  the template and a blocks() method for returning a reference to the
  hash array of any additional named BLOCKs defined in the original
  template text.  An AUTOLOAD method returns values of metadata items,
  allowing a Template::Document reference to be used as the 'template'
  variable.

* The Template::Service module provides a high-level service for
  processing templates, allowing PRE_PROCESS and POST_PROCESS templates
  to be specified along with an ERROR handling hash.

* The Template::Base module defines a common base class for many of
  the toolkit modules.  It implements shared functionality such as a
  constructor, error reporting and handling, etc.  Modules are now
  much easier to sub-class, all using separate new() and _init()
  methods.

* The Template::Config module provides methods for loading and
  instantiating different Template Toolkit modules.  Using this
  factory-based approach makes it far easier to change the default
  object class for a specific part of the toolkit.  e.g.

      use Template;
      use Template::Config;

      $Template::Config::PARSER = 'MyOrg::Template::MyParser';

      # $tt object will create and use a MyOrg::Template::MyParser 
      # object as PARSER
      my $tt = Template->new({ ... })

* The Template module remains, as it ever was, a simple front-end to
  the Template Toolkit.  This creates a single Template::Service to
  which it delegates control for processing templates.  Output is
  returned according to the OUTPUT options specified for the module
  and/or any output option passed explicitly to the process() method.

Plugins and Filters
-------------------

* Added the 'upper' and 'lower' filters for case folding text.

* Added the Date plugin.

Tools and Tests
---------------

* Added the --define var=val option to ttree.

* Added '-- use name --' to Template::Test to switch between multiple
  Template objects specified as a list reference as the second arg
  to test_expect()

* Totally updated the test suite.


Gotchas
-------

Things that have changed between version 1 and 2 that might catch you 
out.  

* Bare CATCH blocks are no longer permitted and must be explicitly
  scoped with a matching TRY.  In most cases, this simply means adding
  a [% TRY %] to the start of any templates that define CATCH blocks,
  and ensuring that the CATCH blocks are moved to the end of the file
  (or relevant place).

       # version 1 - no longer supported
       blah blah blah...some error occurs

       [% CATCH some_kind_of_error %]
          handler template...
       [% END %]

       # version 2
       [% TRY %]
       blah blah blah...some error occurs...

       [% CATCH some_kind_of_error %]
          handler template...
       [% END %]

  Also be aware that this may change the expected output in case of
  errors.  By default, all output in the TRY block up to the point of
  error will be returned, with the relevant catch block, and then and
  further template output appended.  You can use [% CLEAR %] within a
  CATCH block to clear the output from the TRY block, if you prefer.
  TRY blocks can be nested indefinately.

* The ERROR directive is no longer supported.  It was very ill-defined
  anyway and serves no purpose that can't be acheived by defining
  custom filters, error handlers bound to template variables, or
  whatever.  I haven't implemented any special error or logging
  facilities, other than the general purpose exception handling, but
  welcome any thoughts on what or if anything else is needed.

* The ERROR option is also different.  It could previously be used
  to specify an error handling sub-routine, but is no longer required
  (see previous point).  The ERROR option in version 2 is used to 
  define a map of error types to template names for automatic 
  redirection for error handling.

* The current exception caught in a catch block is now aliased to the
  variable 'error' rather than 'e'.  This is much more logical, IMHO,
  and was only prevented previously by 'error' being a reserved word.
  Note that 'e' is still defined, in addition to 'error'.  This may be
  deprecated at some point in the future.

* The use of a leading '$' on variables is no longer optional, and
  should only be used to explicitly to indicate interpolatation of a
  variable name.  Most of the time you *don't* want to do this, so
  leave the '$' off.  This represent a slight shift away from the
  (optional) Perlness of the language, but I think it's a necessary
  step to improve the clarity and consistency of the language.

    As previously discussed on the mailing list, in interpolated text
  (i.e. a "double quoted" string or regular template text with
  INTERPOLATE set), both '$foo' or '${foo}' are interpolated as the
  value of the variable 'foo'.  This is good because it is a de-facto
  standard, consistent with Perl, shell, etc.  But inside a directive,
  [% $foo %] and [% ${foo} %] mean different things, the first being
  equivalent to [% foo %] or [% GET foo %] (the leading '$' is
  ignored) but the second actually fetching a variable whose name is
  stored in the variable 'foo'.  In other words, '${foo}' interpolates
  to the value of foo ('bar', say) and then this is used as the
  parameter to GET (which itself is optional).  Thus, in this case, [%
  ${foo} %] is [% GET ${foo} %] is [% GET bar %].

  This makes more sense if you look at the common example of
  accesing an entry from a hash array using the value of an variable
  as the key (e.g. $hash->{ $key }).  In version 1, the leading '$' on
  variables is ignored, meaning that the following are NOT identical.

      # version 1
      [% hash.$key   %]     # ERROR - '$' ignored => [% hash.key %]
      [% hash.${key} %]     # OK - '$key' is interpolated first

  It gets more confusing if you excercise your right to add optional
  leading '$'s in other places (which is one reason why I've always
  suggested against their use).

      # version 1 - same as above
      [% $hash.$key   %]
      [% $hash.${key} %]

  In particular, that last example should demonstrate the
  inconsistency.  Unlike interpolated text, '$...' and '${...}' are
  not treated the same and '$hash' is not interpolate while '${key}'
  is.  The only consistent solution I can see to this is to make both
  '$xxx' and '${xxx}' indicate interpolation in all cases, so that's
  what I've done.  In version 2, the syntax becomes a lot clearer and
  aligns more closely to a markup language than a programming
  language.  I think this is a Good Thing, but let me know what you
  think...

  Here's the Version 2 summary, assuming INTERPOLATE is set.

      # version 2
      my name is $name
      my name is $user.name
      my name is ${user.name}


      [% GET name %]                 [% name %]
      [% GET user.name %]            [% user.name %]
      [% GET people.fred %]          [% people.fred %]
      [% GET people.$name        %]  [% people.$name %]
      [% GET people.${user.name} %]  [% people.${user.name} %]

      [% INCLUDE header 
         title = "Home Page for $name"
      %]
      [% INCLUDE header
         title = "Home Page for $user.name"
      %]
      [% INCLUDE header
         title = "Home Page for ${user.name}"
      %]

* Changed default TAG_STYLE to only recognise [% ... %] and not the MetaText
  compatability %% ... %% style.  Set TAG_STYLE => 'template1' to accept both,
  or 'metatext' for just %% ... %%

* Changed how error/return values should be returned from user code.
  All errors should be thrown via one of the following:

    die $error_msg;
    die Template::Exception->new($type, $info);
    $context->throw($msg);
    $context->throw($type, $info);
    $context->throw($exception);

* USERDIR and USERBLOCK are not supported (they were experimental and 
  undocumented, anyway)

* $Template::Directive::While::MAXITER is now 
  $Template::Directive::WHILE_MAX and may change again.

* into() filter is now obsolete.  You can now simply assign the output of
  another directive or block to a variable.

    [% x = INCLUDE foo %]
    [% y = BLOCK %]
       blah blah blah 
    [% END %]

* The CASE option has been removed and replaced with the ANYCASE option
  which is the logical opposite.  Directive keywords should now be UPPER
  CASE by default and the ANYCASE option can be enabled to revert to 
  the previous behaviour of accept keywords in any case.

* The IMPORT directive and magical variable have been removed and 
  replaced by a general purpose virtual hash method, import().
  [% IMPORT myhash %] should now be written [% import(myhash) %]
  and [% myhash.IMPORT = another.hash %] should be written as
  [% myhash.import(another.hash) %]