jayk at ion0
Jun 1, 2009, 2:42 PM
Post #9 of 12
There are many 'plugins' that really never should have been plugins.
The methods described in the Extending Catalyst doc were not always
public knowledge and quite a lot got written as plugins when they
should have been something else.
Do not make the mistake of thinking of Catalyst Plugins in the same
way you think of WordPress or MovableType or Drupal plugins. They are
not the same thing at all.
Think more along the lines of apache modules. Plugins are things that
affect the basic functionality of Catalyst, not things that just add a
feature here or there. If it effects core functionality, and _has_ to
be a plugin to access the parts of Catalyst and it's dispatch process
to do it's job, then it should be a plugin... if it doesn't _have_ to
be a plugin in order for it to do it's job, it should not be a plugin.
The fact that the rate limiter _could_ be written as a controller
indicates that it should NOT be a plugin. It doesn't necessarily need
to be a Controller, but it doesn't rely on Cat internals / Dispatch
process, so it should not be a plugin.
Also, plugins affect the core of catalyst and their methods are added
to the $c object. The more plugins you have, the more likely you are
to have conflicts and failures / incompatibilities.. It simply does
not make sense to add anything as a plugin unless it absolutely has to
There are numerous 'plugins' that don't need to be plugins, but are
still for various reasons. Most of the Authentication system, for
example, got moved out of the Plugin namespace almost two years ago.
Only the initial setup hook portion remains as a plugin.
Hope that helps,
On Jun 1, 2009, at 11:11 AM, Matthias Dietrich wrote:
>> 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.
> sorry, I meant Plugin::Authentication - sorry for that! But as I
> understand it, not every plugin module on CPAN should be a plugin?
> But when this is based on opinions, who decides which is a plugin
> and which not?
>> 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.
> I guess you meant "It shouldn't be a controller or a plugin", right?
> Don't get me wrong, I don't want to create this as a plugin under
> all circumstances. I just want to figure out when a module is a
> plugin, when a model and when a controller. But I'm getting closer
> to the truth ;).
> rainboxx Matthias Dietrich
> Freier Software Engineer
> rainboxx | Tel.: +49 (0) 151 / 50 60 78 64
> Tölzer Str. 19 | Mail: matt [at] rainboxx
> 70372 Stuttgart | WWW : http://www.rainboxx.de
> XING: https://www.xing.com/profile/Matthias_Dietrich18
> GULP: http://www.gulp.de/profil/rainboxx.html
> Catalyst-dev mailing list
> Catalyst-dev [at] lists
Catalyst-dev mailing list
Catalyst-dev [at] lists