a lot of methods are in different namespaces.
It was mod_perl1's mistake to not be so modularized in the first place. mod_perl2 does a much better job of this.
the output doesn't work like in CGI, where you just print to STDOUT.
mod_perl coding != CGI coding. A more rigrious API, as opposed to STDIN/STDERR, should be considered a good thing. The best you can say about the CGI method is that it follows the Unix pipe model well. But what works so well for command lines doesn't work so well over networks. It's long past time that we move beyond this.
Also to flush, $|=1 doesn't work, you need to call rflush() for each flush.
Blame Perl for making a default global variable do autoflushing for every single file handle in your program (unless you localize it). Update: Oops, only does it for the currently selected filehandle. Thanks to chromatic for pointing this out.
Actually the biggest problem is that to use mod_perl 2.0 we have a lot of new things.
So you had to upgrade your Perl and Apache versions to get the biggest change in Perl-based web programming since mod_perl was first released? Seems a small price to pay.
If there is any problem with mod_perl2, it's that its documentation is lacking. Such as what you mentioned about converting to the new API.
I'm also very excited about its ProtocolHandlers. One of these days I'll have to get around to writing a Gopher handler.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
In reply to Re: Experiencing with mod_perl 2.0 (1.99)
by hardburn
in thread Experiencing with mod_perl 2.0 (1.99)
by gmpassos
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |