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