http://qs321.pair.com?node_id=446664


in reply to TT PLUGIN_PATH

You can include plugins you have defined yourself that are outside of @INC by specifying a relative (to the program that constructs a new Template object) path.

Supposing the following output of ls -R:

.: Local index.pl ./Local: MyPlugin.pm

...where one might use the module Local/MyPlugin.pm with ``use Local::MyPlugin;'', an argument to the constructor of ``PLUGIN_BASE => 'Local','' would allow you to say ``[% USE MyPlugin %]''.

A trivial example (using the proposed directory structure) may be illustrated, thus:

index.pl:

#! /usr/bin/perl use strict; use warnings FATAL => 'all'; use CGI; use Template; my $tt = Template->new( { PLUGIN_BASE => 'Local', } ); print CGI->new->header; $tt->process( \*DATA, { msg => 'Seems to work' } ) or die $!; exit; __DATA__ [% USE MyPlugin %] <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd "> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <title>[% msg %]</title> </head> <body> <h1>[% msg | make_red %]</h1> </body> </html>

Local/MyPlugin.pm:

package Local::MyPlugin; use base qw(Template::Plugin); use strict; use warnings FATAL => 'all'; sub new { my($self, $context) = @_; $context->define_filter( 'make_red', \&make_red, 0 ); return $self; } sub make_red { my $input = shift; return '<span style="color: #f00; ">' . $input . '</span>'; } 1;

There's a book which explains all this very nicely, personally I found it easier-going than browsing the docs.

As for whether you should use your plugin-defining module elsewhere in your application, I can't see an obvious case where you'd want to use code that inherits from Template::Plugin::Base outside of the context of processing templates but, if you can, there's no particular reason you cannot. I would argue that it makes sense to keep your plugin logic packaged separately, if only to make its purpose obvious to a future maintainer.


MB