On August 6, 2004 7:10 am, Bill Catlan wrote:
> Thanks Cees. That all looks great. I have a thought
> on the conceptual level though. Please note, I am
> half thinking out loud here - just interested in
> others' thoughts.
>
> Should C::A::Plugin perhaps put the plugin methods
> into C::A space, and not the C::A app module? After
> all, the plugin is a /C::A/ plugin, not a 'MyApp'
> plugin.
No way. If I'm running under mod_perl with multiple C::A-derived apps,
I don't necessarily want all of them using this plugin. And if two
plugins have an accidental overlap in sub names, we have serious
problems - one of the miriad of apps (developed independantly for the
same ISP server) could just not work unexpectedly.
By putting the plugin methods into the app namespace, this doesn't
happen.
> Then, when the app module does its normal 'use base
> C::A;', it will get the "registered" plugins. C::A
> would simply provide a class method
> 'register_plugins', or grab them from a config file /
> ENV variable.
>
> As a case in point for why this could be beneficial,
> the 'jedit' project eventually makes certain plugins
> "standard", allowing the base appplication - the base
> platform, if you will - to evolve through community
> contributions.
If the "jedit" package used a plugin, the plugin would be in the jedit
namespace - which makes it available to anything derived from jedit's
package.
---------------------------------------------------------------------
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
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| 
