plugins; was Re: [Catalyst] debug mode

[mreece at vinq.com]

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

  $c->twiddle_with_session();

than

  $self->twiddle_with_session($c);

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
$c.


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?

  __PACKAGE__->mk_accessors('_context');

  sub _ACTION : Pricvate {
    my ($self, $c) = @_;
    $self->_context($c);
    $self->SUPER::_ACTION($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