[Catalyst] External plugins (continued)

[Christopher H. Laco]

Ovid wrote:
> --- 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
> 

Ya know, I did a lot of plugin hokey pokey in Handel in terms of plugin
order, LoadPlugins (load only the specified ones), IgnorePlugins (load
all but the ones list), etc. It turns into a Charlie Foxtrot quite easily.


The more I think about this, the more I think that just sticking with
the DWIM version of:

use Catalyst qw/Static Authentication +my::other::plugin,
+yet::some::other::ns/;

is the best way to go.  The closer we move towards a Plugin directory,
the worse the needed options become.

If there is a plugins directory, we then need the ability to specify
which plugins to load, or not load, and in what order, possibly using
the visitor model to register each one.

Keeping things back to the use statement keeps it to a simple DWIM
without much more code. The order specified is the order loaded without
any extra magic like it is now. Anything not listed is not loaded
without any extra code.

If any of that makes any sense...

-=Chris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060217/51b3259d/signature.pgp