[Catalyst] Plugins vs. Base Controllers

[John Napiorkowski]

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.  There are a lot of plugins to add convenience methods to the context object, like the datetime plugin, which are mostly thin wrappers around existing CPAN modules.  This really just makes it so you don't have to add 'use xxxxx' at the top of each controller that needs it, but I can see trouble with this in terms of the namespace collision you mentioned.  Also a lot of these convenience plugins don't offer the full functionality of the CPAN module they are wrapping and then you end up using it the normal way instead.

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.

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.

--john


----- Original Message ----
From: Matt S Trout <dbix-class at trout.me.uk>
To: The elegant MVC web framework <catalyst at lists.rawmode.org>
Sent: Friday, August 18, 2006 9:40:46 AM
Subject: Re: [Catalyst] Plugins vs. Base Controllers

Mark Blythe wrote:
> Spinning this off into a new thread.
> 
>> So make it a controller base class.
>>
>> People make everything a plugin by default because it seems like a good idea
>> at the time. This has resulted in massive compatibility issues due to
>> namespace collisions.
>>
>> Don't Do It.
> 
> I've pondered the "controller vs. plugin" choice myself several times,
> and I see I'm not alone.  I see the namespace issue with plugins, but
> does the potential for conflict make all plugins evil?  This is
> another area where a clear best practices would be quite helpful.
> Matt, could you share your thoughts on when it's appropriate to choose
> a plugin over a base controller and vice versa?
> 
> I'm guessing plugins become necessary when you need to get your hooks
> into a specific piece of Catalyst framework logic in order to achieve
> your goal -- like overriding and extending a method.  Is a controller
> preferable in all other cases?

That and the request cycle. Other than that, it probably doesn't need to be a 
plugin. The main reason things have been made plugins is because it's (a) 
convenient, (b) there are existing examples, (c) "everybody else seems to be 
doing it", (d) the name "Plugin" makes people happy. I'd really quite like a 
similar system for having model, view, controller, engine and dispatcher 
plugins, but we don't have enough of them to figure out the use cases yet :(

If your only argument is "I need $c" you can usually do a controller, view or 
model with an ACCEPT_CONTEXT method. Often you only actually need the app 
instance (i.e. the "MyApp" class name in 5.70) not the full request context.

If you want to pass stuff to the view, an object or a subref in the stash is 
usually best.

Things like Session and Authentication make perfect sense as plugins; form 
validators don't. It makes common controller base classes for CRUD or whatever 
(and yes, scaffolding code :) much harder because the form validators all seem 
to be plugins and, wahey, you can only have one $c->form method.

-- 
      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 at 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/