[Catalyst] Calling form plugin authors: these should not be plugins

Matt S Trout dbix-class at trout.me.uk
Mon Nov 20 15:56:22 GMT 2006


On 20 Nov 2006, at 15:29, John Napiorkowski wrote:

> --- Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:
>
>> I looked at the code of some plugins - it's quite
>> frequent that they
>> don't do anything beside just putting the method
>> calls from some
>> original module to the context object.
>> I don't  see any advantage in using $c->some_method
>> instead of
>> Some::Module->some_method. This unnecessarily
>> complicate the
>> inheritance tree.  The only marginal benefit is that
>> they state - this
>> module can work with Catalyst.
>
> One thing that would help with this is if there was
> some clear instructions about how to add external perl
> modules to a global namespace in Catalyst.  I find I
> end up with:
>
> package myapp::Controller::foo;
>
> use Other::Module;
> use Another::Usefull::Module;
>
> at the top of a lot of controllers.  I usually end up
> creating a base controller with all those modules I
> typically use and inherit from that instead of from
> Catalyst Controller.  People who did mod_perl
> programming are used to preloading stuff and having it
> available, however I haven't figured out how this
> works in Catalyst.

If you care about code re-use, use-ing modules where you need them  
(or use-ing / use base-ing a module that loads them) is the only way  
to go.

I dunno about "how this works in Catalyst", it's just perl and works  
the same way it always does ...

-- 
Matt S Trout, Technical Director, Shadowcat Systems Ltd.
Offering custom development, consultancy and support contracts for  
Catalyst,
DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for  
details.
+ Help us build a better perl ORM: http://dbix- 
class.shadowcatsystems.co.uk/ +





More information about the Catalyst mailing list