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/ +
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
