[Catalyst] External plugins (continued)

[Christopher H. Laco]

Brandon Black wrote:
> 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
> 
> 

And is +Foo::Bar  really MyApp::Plugin::Foo::Bar?
What about the people who want +Foo::Bar to really load Foo::Bar ?

-------------- 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/eafb0d86/signature.pgp