Re: [Templates] Patch to implement USE_SINGLETON idea in CAP::TT

> Hello, Cees.

On Thu, 27 Jan 2005 16:48:29 -0800, C. Chad Wallace
<cwallace@xxxxxxxxxxxx.xxx> wrote:
> Hello, Cees.
> 
> Do you recall your message about a singleton Template object on the "TT
> in callback" thread on the Templates mailing list?  Well, I liked it so
> much I went ahead and implemented it.  I've attached a patch for
> CGI::Application::Plugin::TT version 0.04 if you're interested.
> Hopefully, you haven't already implemented it yourself. :-)

Thanks for this, but I have actually already implemented it ;).  I
just never got around to announcing it yet or uploading it to CPAN. 
You can download version 0.05 from here if you want to take a look:

http://cees.crtconsulting.ca/perl/modules/CGI-Application-Plugin-TT-0.05.tar.gz
http://cees.crtconsulting.ca/perl/modules/CGI-Application-Plugin-TT-0.05/

I approached it from a slightly different way then what we talked
about on the mailing list.  Instead of configuring the object by
calling $self->tt_config(...) you can now provide all the options when
you 'use' the module.

package My::App;

use base qw(CGI::Application);
use CGI::Application::Plugin::TT (
              TEMPLATE_OPTIONS => {
                        POST_CHOMP   => 1,
                        FILTERS => {
                                     'currency' => sub { sprintf('$
%0.2f', @_) },
                        },
              },
);

When you use the module this way, it automatically creates a singleton
that is local to the module that loaded it (ie anytime package My::App
asks for a template object, it will return the same TT object over and
over again, however Your::App will get it's own TT object).

The singleton will follow inheritance as well, so any subclasses of
My::App would get the same TT object (unless they themselves 'use' the
plugin to create a new TT object to override it).

So maybe it doesn't quite make sense to call it a singleton in the
traditional sense, since you can still have multiple TT objects in
memory, but each object will be persistent and accessible only in a
certain class hierarchy.

I've also added a method to change the INCLUDE_PATH dynamically.called
tt_include_path (as per Perrin's suggestion).

I'd appreciate any feedback on the implementation, especially any
reasons why this might be a "bad idea".

Cheers,

Cees

_______________________________________________
templates mailing list
templates@xxxxxxxxxxxxxxxx.xxx
http://lists.template-toolkit.org/mailman/listinfo/templates