NAME
    Template::Plugin::Cache - cache output of templates

SYNOPSIS
      [% USE cache = Cache%]
    
      [% cache.inc(
                   'template' => 'slow.html',
                   'keys' => {'user.name' => user.name},
                   'ttl' => 360
                   ) %]

DESCRIPTION
    The Cache plugin allows you to cache generated output from a template.
    You load the plugin with the standard syntax:

        [% USE cache = Cache %]

    This creates a plugin object with the name 'cache'. You may also specify
    parameters for the File::Cache module, which is used for storage.

        [% USE mycache = Cache(namespace => 'MyCache') %]

    The only methods currently available are include and process,
    abbreviated to "inc" and "proc" to avoid clashing with built-in
    directives. They work the same as the standard INCLUDE and PROCESS
    directives except that they will first look for cached output from the
    template being requested and if they find it they will use that instead
    of actually running the template.

      [% cache.inc(
                   'template' => 'slow.html',
                   'keys' => {'user.name' => user.name},
                   'ttl' => 360
                   ) %]

    The template parameter names the file or block to include. The keys are
    variables used to identify the correct cache file. Different values for
    the specified keys will result in different cache files. The ttl
    parameter specifies the "time to live" for this cache file, in seconds.

    Why the ugliness on the keys? Well, the TT dot notation can only be
    resolved correctly by the TT parser at compile time. It's easy to look
    up simple variable names in the stash, but compound names like
    "user.name" are hard to resolve at runtime. I may attempt to fake this
    in a future version, but it would be hacky and might cause problems.

QUESTIONS
  How is this different from the caching already built into Template Toolkit?
    That cache is for caching the template files and the compiled version of
    the templates. This cache is for caching the actual output from running
    a template.

  Who would benefit from this cache?
    There are two situations where this might be useful. The first is if you
    are using a plugin or object inside your template that does something
    slow, like accessing a database or a disk drive or another process. The
    DBI plugin, for example. I don't build my apps this way (I use a
    pipeline model with all the data collected before the template is run),
    but I know some people do.

    The other situation is if you have an unusually complex template that
    takes a significant amount of time to run. Template Toolkit is quite
    fast, so it's uncommon for the actual template processing to take any
    noticeable amount of time, but it is possible in extreme cases.

  Why don't you let users choose which Cache::Cache subclass they want to use?
    Because Cache::FileCache is by far the fastest in nearly all cases.

  Will you be offering support for other cache modules?
    I could, if there is a demand for it.

  Any "gotchas" I should know about?
    If you have a template that produces side effects when run, like
    modifying a database or object, these side effects will not be captured
    and caching will break them. The cache only caches actual template
    output.

    Of course, if you have a template which produces side effects, you are a
    very naughty person and you get what you deserve.

AUTHORS
    Perrin Harkins (perrin@elem.com <mailto:perrin@elem.com>) wrote the
    first version of this plugin, with help and suggestions from various
    parties.

COPYRIGHT
    Copyright (C) 2001 Perrin Harkins.

    This module is free software; you can redistribute it and/or modify it
    under the same terms as Perl itself.

SEE ALSO
    Template::Plugin, Cache::FileCache