[Catalyst-dev] Plugin or controller?

[J. Shirley]

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

> Hi,
>
>  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) ;).
>
> The module provides a thin wrapper around Algorithm::FloodControl and
> implements one function that can be called within a controller action to
> decide, what to do.  It's like the Authorization plugin.  And because it
> only implements this helper function, the controller namespace is a bit
> confusing.
>
>
> matt
>

I'm not sure why $self->flood_control is more confusing than
$c->flood_control.  But I'd also probably stuff this in a Model...
$c->model('FloodControl')->register_attempt( $c->controller, $c->user->login
|| $c->req->address) looks more meaningful to me... again, just opinions.

A controller should determine, via configuration, how it can be flooded.  If
your application needs such things, I would say that something upstream from
Catalyst itself is a better solution (but applying this at a root chain
would accomplish the same thing).

If it is a plugin, you couldn't allow different rates on a per-controller
basis unless you start giving it per-controller configuration... at which
point there is a bad design when a plugin starts being controller specific.
Exempting a controller from rate limiting would also be difficult from a
plugin perspective.  From a model perspective, the same holds true...

There isn't anything in this code that should affect core dispatching or the
framework itself, which is what plugins are for (and that was Tom's point,
as a general rule of thumb if you can't justify a plugin it should not be a
plugin).


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