Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Jesse Erlbaum wrote: Philippe -- Check out the guide: Check out the books: Check out the success stories: Is that your answer? I was hoping for specific examples, not hand-waving. I like to think that Part III (Chapters 11-17) of the mod_perl Developer's Cookbook does some of that. authentication is a good example of how mod_perl enables life outside of CGI scripting. if you require authentication in your application, auth handlers allow you to entirely remove authentication from your content handlers. mod_perl allows you to let your content handlers to focus on content - all other parts of your application (authentication, session management, proxying, URL rewriting tricks, etc) can programmed at the server level via other parts of the request cycle. I'm talking about this at a very basic level at OSCon this year (as I did last year), but you might be interested in my slides from YAPC2002 to get a general feel for it (and ApacheCon if you want to see the more twisted side of what mod_perl opens up). http://www.modperlcookbook.org/~geoff/slides/ HTH --Geoff
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
Hello, GYmod_perl allows you to let your content handlers to focus on content - GYall other parts of your application (authentication, session management, GYproxying, URL rewriting tricks, etc) can programmed at the server level GYvia other parts of the request cycle. I think the question isn't why is Apache::Registry not sufficient to handle all functions within an HTTP request but why is it bad to use Apache::Request specifically for the content generation phase? Perrin had some good practical reasons for this--caused by the generated-namespace, sub-wrapped, eval'ed nature of Apache::Registry. I totally agree with the fact that Apache::Registry can introduce many hard-to-debug-problems. I've had enough headaches debugging some of these issues myself. It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. I mean, even from the lowest common denominator CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. I have found that often the Apache::Registry functionality of not having to restart servers when simple scripts change is worth the potential of bugs tickled by the Apache::Registry sub-wrap approach. I think it's a fine tool for simple content generation scripts and that it doesn't limit you at all in that aspect. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer1-800-555-TELL Voice 650-930-9062 Tellme Networks, Inc. Fax 650-930-9101 --
Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandlerphilosophy)
It's unclear to me, though, that there are unimaginably cool things you can get to in a real content handler that you can't get to from an Apache::Registry script--which seems to be the assertion. well, if you consider that you still get access to $r and all its treasures from Apache::Registry, then that's mostly true. I mean, even from the lowest common denominator CGI you can get all parts of the incoming HTTP request, plus output arbitrary headers. it's when you use Apache::Registry as a wrapper for your legacy CGI scripts that the difference really begins to show. consider something like this http://www.perl.com/pub/a/2002/02/20/css.html while most templating systems don't have this issue with HTML entities, using the mod_perl API gives you ways of handling tasks like CSS protection behind the scenes. and I think that's unimaginably cool. other cool stuff comes at the end of this talk, http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2002/oo-mod_perl-printable.ppt.gz which touches on Apache::Registry-as-legacy-CGI-wrapper limitations see also http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-CachePOSTRegistry-0.01.tar.gz which handles the issue of merging legacy CGI Registry scripts with POST data issues and http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-HEADRegistry-0.01.tar.gz which addresses the fact that Registry does not properly handle HEAD requests. given all of that but not wanting to speak for anyone else, I think that once you buy into the-mod_perl-API-is-better approach, there are really few reasons to use Registry over content handlers, as Registry adds an additional but unnecessary level of complexity and indirection. --Geoff
