[Catalyst-dev] Plugin or controller?

Tomas Doran bobtfish at bobtfish.net
Mon Jun 1 17:10:02 GMT 2009


Matthias Dietrich wrote:
>> You haven't in any way explained why you think it _needs_ to be a plugin.
>>
>> Therefore, it doesn't need to be, and so shouldn't be. ;)
> 
> if you argue that way, nothing needs to be anything (because opinions 
> are different) ;).

No, sorry.

This isn't an arbitrary choice. Some things _NEED_ to be plugins (i.e. 
need to be composed onto the application's @ISA).

The _only_ things which need that are things which explicitly want to 
change the way setup works, and even then quite often you can use an 
application class role.

If it doesn't alter basic framework operation and dispatching in such a 
way the it _NEEDS_ to be on @ISA for your application class, then it 
shouldn't be in the Catalyst::Plugin namespace.

The canonical example of this being plugins which provide $c->form = 
what a massive bucket of fail that one is - changing form system part 
way through an applications life, or running more than one form system 
is more common than you'd think.

As you're considering an alternate implementation of flood control to 
the one which already exists, this also clearly makes a good case that 
neither of them should be a plugin.

I'd recommend going and re-reading the advice in 
Catalyst::Manual::ExtendingCatalyst. If after reading that it still 
isn't clear as to why this should not be a plugin, please tell us 
how/why/where it should be expanded to be more clear, and I'll do so.

Thanks
t0m



More information about the Catalyst-dev mailing list