[Catalyst] External plugins (continued)

[Brandon Black]

On 2/17/06, Christopher H. Laco <claco at chrislaco.com> wrote:
> 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...
>

I agree, but I still think the Plugins directory is useful for
organizational and shorthand.  Don't scan it and try to autoload
anything, just make MyApp::Plugin an automatic plugin prefix like
Catalyst::Plugin is.

Then we can do "use Catalyst qw/ StaticSimple DoTheDishes
+Foo::Bar/;", and it will find Catalyst::Plugin::StaticSimple,
MyApp::Plugin::DoTheDishes, and Foo::Bar.

-- Brandon