[Catalyst] External plugins (continued)
Ovid
publiustemp-catalyst at yahoo.com
Fri Feb 17 22:20:18 CET 2006
--- Matt S Trout <dbix-class at trout.me.uk> wrote:
> > use Catalyst qw(
> > DateTime
> > +MyApp::Custom::Plugin::DoesTheDishes
> > );
> >
> I dunno if people want to have a debate over exactly what name to
> use, but I think in general this is a good idea.
Unless I'm misunderstanding folks, this sounds like something they
want. I've noticed that in writing the tests, I've stumbled across the
problem that plugins are computed, rather than determined. For
example, in one test we have this:
my $plugins = join(
', ',
sort grep { m/^Catalyst::Plugin/ }
@{ $class . '::ISA' }
);
$c->response->header( 'X-Catalyst-Plugins' => $plugins );
This makes it a bit harder for me to test. I think providing a bit of
introspection here would be useful so that we could do:
my @plugins = $c->plugins;
In Catalyst::setup_plugins(), we see that this is a class method (which
seems appropriate), so this could be easily implemented by a public
"plugins()" method for reading and a protected "_set_plugin()" or
something similar so that Catalyst can store this data. Thus, your app
can query itself to determine what plugins it supports (useful is a
plugin wants to know if other plugins are available).
The downside of this is that anyone who has already done the "use base"
trick to add a plugin won't have this plugin name available from
$c->plugins. Of course, since they're not using that method, it may
not be a problem.
Does anyone have any problem with this approach?
Cheers,
Ovid
--
If this message is a response to a question on a mailing list, please send follow up questions to the list.
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
More information about the Catalyst
mailing list