[Catalyst-dev] Plugin or controller?

J. Shirley jshirley at gmail.com
Mon Jun 1 16:56:22 GMT 2009


On Mon, Jun 1, 2009 at 9:46 AM, Matthias Dietrich <mdietrich at cpan.org>wrote:

Why couldn't that allow different rates on a per-controller basis?  Because
> you define a name for the rates it can be anything.  Even, as far as I
> understand the module Algorithm::FloodControl, the actual value for the r=
ate
> would then be available from within any controller without using this
> controller as a base controller wherever I want to access the rate limit.=
  A
> rate limiting is not always bound to only one controller; it depends on h=
ow
> you use the module.
>
>  There isn't anything in this code that should affect core dispatching or
>> the framework itself, which is what plugins are for
>>
>
> Hm, I don't see why Plugin::Authorization falls under this but not
> Controller::RateLimit.
>
>
So, first, there is no such thing as Catalyst::Plugin::Authorization.  When
you first mentioned it I assumed you simply meant Authorization::ACL or
Authorization::Roles.  The latter should not be a plugin in my opinion, but
a model.

To talk of Authorization::ACL,  the answer to why it is a plugin is very
simple.  It modifies dispatching and extends Catalyst.  Before the request
is sent to the controller, the aggregated ACL rules are checked on each
request and Catalyst's execute method is wrapped.  You can't do this in a
controller, and it is site-wide.

That makes it a plugin.

If you are trying to access an application wide object, it's a model.  As
such, I again restate that Catalyst::Controller::RateLimit should simply be
either a Catalyst::Model::Adaptor or a customized Model.  It shouldn't be a
controller or a model, since it does have a benefit of being application
wide.

-J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst-dev/attachments/20090601/9=
60ebabf/attachment.htm


More information about the Catalyst-dev mailing list