Michael Peters wrote:
[sorry Michael, I meant to send this to the list]
Stephen Howard wrote:
Although it is not really compatible with this approach, one of the
nice things about many plugin systems is that while they all reside in
a Foo::Plugin:: namespace, the mechanisms for importing the plugin
usually lets you drop the Foo::Plugin:: prefix when referring to it
and it will still do the Right Thing. Not really going anywhere with
this, as it would require a different approach, but was looking at the
character count of
> use CGI::Application::Plugin::ValidateRM (qw/check_rm/);
versus something like
$app->load_plugin('ValidateRM', qw(check_rm));
That's an interesting idea... I wonder what others would think of
allowing both? If we have a standard way of importing, naming, etc...
for the plugins then this might act as sort of a pseudo way of enforcing
it. It should be trivial to add that sub to C::A and the plugin's author
would need to make sure that their plugin worked that way.
I have been playing with plugins lately as well, but my plugins can be
described as html widgets: they supply parts of the UI.
I needed some sophisticated html controls that I wanted to add to
several cgi-apps, but they needed to supply runmodes as well (these are
editors for certain features of my app, with minor adjustments depending
on where in the site they are used). I suppose you could call those
mixins. In this case I went with Marks approach, using Exporter to
import the runmodes into my app, and offering a setup_plugin method that
I can call in my app's setup. I feel this is the correct approach for
larger, more complex plugins that can do many things.
I also needed a way to add simpler html widgets in various places, that
would show stuff based on the context (things like putting a page list
for a given category in a side bar, pretty basic stuff).
I ended up coding these with an approach that is similar to
$app->load_plugin('pluginname')
The thing I don't like about this versus the Exporter path, is that the
plugin is imported during runtime instead of compile time, making it
harder to test and debug.
The plus side is that the load_plugin method can also call any setup
routines in my plugin, and it may even call other methods as well, and
all this transparently.
Rhesa
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
|
