As I worked on a new plugin system for HTML::Template [0], I recycled code from
CGI::Application's new plugin system [1].
As I reflected on this, CGI::Application has developed a nice plugin system
which is easily re-usable on it's own.
It is most similar to Class::Trigger [2], but I think the CGI::App solution is
more advanced for these reasons:
- We look up the inheritance tree for more callbacks to execute
- We allow arguments to be passed into the callbacks, customizing how each
callback can work, and creating clearer, more explicit syntax than passing
through the object.
- We have a specific callback ordering, and we expect to soon solve the
problem of making this ordering to be sufficiently flexible to address
most plugin needs.
- Class::Trigger requires your object be implemented as blessed hashref
(Gasp!). We could solve this in our implementation by adding a method for
'installed_callbacks()', which could be trivially overridden if the
callbacks needed to be stored in the object a different way.
So I would like to move CGI::App's plugin system into it's own module, which
wouldn't change anything from a user's perspective, except perhaps where the
related documentation is located.
I could see what we have possibly being merged into a future enhanced version
of Class::Trigger, which CGI::App would then have it's own plugin for, to keep
compatibility with the names we've already established.
0. http://use.perl.org/~markjugg/journal/26089
1. http://www.cgi-app.org/?Plugins
2. http://search.cpan.org/perldoc?Class::Trigger
Collaborators welcome! Let's keep discussing it on the CGI::App mailing
list and #cgiapp on irc.perl.org.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
ma...@su... Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
|
