[Catalyst] Calling form plugin authors: these should not be plugins

[Jon]

Hear, hear!  One of the things I had real trouble getting my head around
on introduction to Catalyst was why things like FormBuilder and Widget
had to be plugins.  Ended up wasting a lot of time trying to write code
that I couldn't see the sense in.  Perhaps
Catalyst::Manual::WritingPlugins could be augmented with a set of
guidelines or tests for what should and shouldn't constitute a plugin vs
component?

-- 

Jon

On Mon, 2006-11-20 at 10:19 +0000, Matt S Trout wrote:
> Another day, another stupid problem reported on #catalyst because  
> somebody thought it was a good idea to write a form handler as a  
> plugin (FormBuilder this time).
> 
> Form plugins do not need to interrupt the request cycle (like  
> Authentication, Static::Simple, Session etc. do).
> 
> Form plugins do not need to communicate directly to the engine
> 
> Form plugins all seem to want $c->form and thus are a disaster for  
> code re-use between applications (expect C::P::HTML::Widget, which  
> wants $c->widget and as such is a reasonably self-contained disaster :)
> 
> There's no reason why these can't be controller base classes, action  
> classes, whatever. They Do Not Belong As Plugins.
> 
> Please can the authors or current maintainers of at least -
> 
> C::P::FormValidator
> C::P::FormValidator::Simple
> C::P::FormBuilder
> C::P::HTML::Widget
> 
> take a long hard look at their code, and if you can't find a reason  
> this *has* to be a plugin, please make it something else. I have a  
> feeling the first on that list is maintained by core; if that's so,  
> I'll happily port it myself sometime in the next couple weeks to give  
> people a guide to work to.
> 
> I intend to mark all these plugins deprecated by the master plugin  
> documentation for the next major release unless somebody cares enough  
> to argue otherwise.
>