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