Quoting Bill Catlan <[EMAIL PROTECTED]>: > 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.
Hi Bill, That is how the C::A::Session module currently does it. But there are some concerns with this approach, especially when working in a shared environment like mod_perl. There could be multiple application running on the webserver that all use CGI::Application. Once one of them loads a plugin, those methods would be visible to all applications. Some would consider that a benefit, but it has the potential to cause problems. As a quick example of a problem that could arise. Lets say I have an AUTOLOAD method in my app, and I am looking to capture calls to a method called 'session'. My app runs fine, until someone installs another application that uses C::A::Session. This now adds a 'session' method to CGI::Application, and now all the sudden my app is broken, as my AUTOLOAD no longer traps the call to 'session', since there is now a real 'session' method in CGI::Application. Or to change the example slightly, say I wrote my own session module, and stuck a use base qw(CGI::Application My::Session::Module) in my app. Everything works fine until someone else uses C::A::Session and things start to break in my app. Those examples may be a little contrived, but the possibilities are real. This isn't an issue when working with a plain CGI script, or commandline script, but can cause problems in persistent environments like mod_perl and SpeedyCGI where you have multiple applications loaded at the same time that could be doing wildly different things. Cheers, Cees --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
