On Fri, 22 Oct 2004 10:16:21 -0400, Michael <[EMAIL PROTECTED]> wrote: > At first I didn't like this suggestion since I think you should know > what environment you're in. I you're developing an app for both > environments then I think you should just develop it as a normal cgi and > then use something like Apache::Registry or Apache::PerlRun. My initial > target audience was developers who use CGI::App in an all mod_perl > environment and don't want to mess with any old CGI style code.
It becomes more important when you want to release an application to the public, and make it compatible in multiple environments. I usually build my applications so that they can be run as plain CGI, but usually end up running then under PersistentPerl in production. > But the more I think about the more I don't dis-like the idea. It > doesn't do any harm to those who want to use it as is. My main concern > with it is that if the developers think that it will run the same in a > both mod_perl and mod_cgi then they are mistaken. For instance, if they > used my plugin while developing under vanilla CGI then they would have > access to all of CGI.pm's methods (html generation, etc). If they then > switched to mod_perl (even under Apache::Registry) then it would all break. But if the developer knows the limitations of each of the modules, then they can build to a common subset that will work in all of these cases. I usually only use CGI.pm for the basics (accessing form params and cookies, and handling file uploads). I think it just comes down to documentation. Make sure the developer knows what to expect when working in the different environments. Cheers, -- Cees Hek --------------------------------------------------------------------- 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]
