Hello,

GY>there was a more advanced Apache::FakeRequest floating around somewhere...

TK>I knew this script (it was posted here, too), and while it is definitly
TK>better than Apache::FakeRequest, it still doesn't handle dir_config
TK>calls.

That's my script. The caveat is, that it will *never* be possible to
simulate mod_perl entirely--that would be so complex that you might as
well have everybody run a single-child Apache with mod_perl instead.

We do this for our mod_perl developers. There is perl -wc for simple
syntax checking, the apr script for running dead-simple mod_perl scripts
for debugging, and then everybody runs a small Apache against their own
conf file to test stuff.

GY>any chance you can expand the existing Apache::FakeRequest
GY>and offer a patch?

TK>Sure I could try to patch Apache::FakeRequest, but I think the
TK>changes are quite fundamental. What to the mantainers of
TK>Apache::FakeRequest (or mod_perl) think of this?

I agree that the changes are quite fundamental. I haven't really found
Apache::FakeRequest terribly useful. It doesn't really make debugging
mod_perl handlers any easier by itself. Rather than patching it, perhaps
you could subclass it or replace it altogether.

TK>Is it possible to subclass mod_perl or Apache::Request from
TK>outside of Apache (i.e. in a plain perl environment) ?

Nope, as you guessed. :(

TK>If not (which it seems to be), what would be the best way to
TK>implement all (more or less..) mod_perl methods and subclasses
TK>(Apache::Request et.al) ? Can one use the C code that mod_perl
TK>is based on? (Well, I guess I can't because I've never done any real
TK>C coding ...) ?

The "best" way to do it would probably just be to write code for 'em all.
I think many web developers have many of the pieces lying around anyway
from web client libraries. The hard work is in faking out everything and
matching the API. But then you run into the problem that the code you're
making isn't really mod_perl and Apache anyway.

I'd say that having something "pretty good" for doing fast testing of
mod_perl scripts is good, but you'll never be 100% mod_perl unless you're
using mod_perl itself. :)

Humbly,

Andrew

----------------------------------------------------------------------
Andrew Ho               http://www.tellme.com/       [EMAIL PROTECTED]
Engineer                   [EMAIL PROTECTED]          Voice 650-930-9062
Tellme Networks, Inc.       1-800-555-TELL            Fax 650-930-9101
----------------------------------------------------------------------

Reply via email to