plugins; was Re: [Catalyst] debug mode

mreece at mreece at
Tue Jun 5 16:04:03 GMT 2007

if the catalyst base controller class provided an easy way to access $c
from a utility method (vs an action method, which receives $c
'automatically'), then i think plugins might be a little less popular.

some of my bits have ended up as controllers because i'd rather




session is just an example here, it could need something from $c->config,
$c->request..  it doesn't strike me as particularly wrong for the methods
to live on $c when they will primarily only be calling other methods on

still, depending on frame of reference, i've moved/developed some things
to/as base controllers, and it has helped to have something like this in
my Base::Controller, but maybe it should come for free?


  sub _ACTION : Pricvate {
    my ($self, $c) = @_;

> On Tue, Jun 05, 2007 at 08:40:52AM -0400, Matthew Pitts wrote:
>> On Tue, 2007-06-05 at 01:18 +0100, Matt S Trout wrote:
>> > On Mon, Jun 04, 2007 at 12:55:38PM -0700, Dylan Vanderhoof wrote:
>> > > Oh, missed this email.  Yours looks better than mine.  =)
>> >
>> > Except for being a performance hit on every single method call on $c
>> (there's
>> > a reason I keep telling people not to make everything a plugin ...).
>> Am I correct in saying that the NEXT overhead is proportional to the
>> number of packages in the ISA chain and not the number of methods the
>> plugins override? If so, then if I were to bring all my plugins into one
>> big "framework" plugin would that improve the NEXT performance?
> Or you could avoid making them plugins. 9 times out of 10 they should've
> been a model, a controller base class or an external utility module - see
> the ExtendingCatalyst POD for more info.
> --
>       Matt S Trout       Need help with your Catalyst or DBIx::Class

More information about the Catalyst mailing list