On 10/21/05, Andy Wardley <[EMAIL PROTECTED]> wrote:
> Yes, it looks like you might be re-inventing what the context filter()
> method does. You call it with a filter name and optional arguments and
> it returns you the filter or undef if it can't be found.
>
> Here's an untested example of a plugin that installs a 'multifilter'
> filter when loaded.
>
> package Template::Plugin::Multifilter;
> use base 'Template::Plugin';
>
> sub new {
> my ($class, $context) = @_;
> $context->define_filter( multifilter => sub {
> multifilter($context, @_);
> });
> }
>
> sub multifilter {
> my ($context, $text) = @_;
>
> foreach my $filter in (@LIST_OF_FILTERS) {
> my $filter = $context->filter($filter)
> || next;
> $text = &$filter($text);
> }
> return $text;
> }
Ah ha. Thanks.
For anyone following along, the bit that's missing here is the ability
to tell the template about additional plugins after the Template
object has been created.
This works:
# Map plugin names to the filters they provide
my %filter_in = (
Clickable => 'clickable',
RecogniseRTBug => 'rtbug',
RecogniseSVNRev => 'svnrev');
# List the plugins to run, in order
my @plugins = qw( Clickable RecogniseRTBug RecogniseSVNRev);
# XXX Previous two variables should be initialised from a user
# supplied config file.
sub multifilter {
my ($context, $text) = @_;
foreach my $plugin (@plugins) {
# Make sure the plugin has been loaded
my $plugin = $context->plugin() || next;
# Run the filter for this named plugin
my $filter = $context->filter($filter_in{$plugin_name}) || next;
$text = &$filter($text);
}
return $text;
}
The only thing I'm not happy with is the duplication between
%filter_in and @plugins. Is there any mechanism I can use that, given
a plugin name (or a plugin object) that can tell me the name of the
filter method in that plugin, without needing to maintain a separate
mapping?
N
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates
