[Catalyst] Plugins vs. Base Controllers

[Matt S Trout]

John Napiorkowski wrote:
> I've been thinking that a plugin is something that usefully hooks into the catalyst process, like authentication and sessioning or extends the existing functions, like the dumper plugin extends the log object.

Actually, the Dumper plugin is strongly disrecommended for the moment; the 
author and I discussed on IRC and he had an epiphany and is figuring out a 
saner way to rewrite it.

> I try to think of controllers are encapsulating some bit of logic that I want to reuse.  Like I have a feed controller that takes a list of uris pointing to some sort of feed (rss, atom, etc) and returns each feed in a common translated format.  This is something I need in several places on my site, so I just do a subrequest to an action which is subclassing that base controller.  This could have been a plugin I guess but is seems more like a controller to me.

That's how I'd do it.

> On a side note if anyone has a working useful example of ACCEPT_CONTEXT I'd be glad to see it.  I can see the value of this but no matter how often I reread the doc on it I just don't get it.

C::M::DBIC::Schema injects an ACCEPT_CONTEXT method into the composed model 
classes to get the resultset return - something like

package MyApp::Model::DB::Foo;

sub ACCEPT_CONTEXT { my ($self, $c) = @_; return 
$c->model('DB')->schema->resultset('Foo'); }

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +