[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