Re: RFC: new module: Apache::FakeEnv
Hello, GYthere was a more advanced Apache::FakeRequest floating around somewhere... TKI knew this script (it was posted here, too), and while it is definitly TKbetter than Apache::FakeRequest, it still doesn't handle dir_config TKcalls. 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. GYany chance you can expand the existing Apache::FakeRequest GYand offer a patch? TKSure I could try to patch Apache::FakeRequest, but I think the TKchanges are quite fundamental. What to the mantainers of TKApache::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. TKIs it possible to subclass mod_perl or Apache::Request from TKoutside of Apache (i.e. in a plain perl environment) ? Nope, as you guessed. :( TKIf not (which it seems to be), what would be the best way to TKimplement all (more or less..) mod_perl methods and subclasses TK(Apache::Request et.al) ? Can one use the C code that mod_perl TKis based on? (Well, I guess I can't because I've never done any real TKC 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-TELLFax 650-930-9101 --
Re: RFC: new module: Apache::FakeEnv
Hi! Geoffrey Young: there was a more advanced Apache::FakeRequest floating around somewhere... I think this was it, but I swore it was something on the dev@ list: http://marc.theaimsgroup.com/?l=apache- modperlm=98719810927157w=2 I knew this script (it was posted here, too), and while it is definitly better than Apache::FakeRequest, it still doesn't handle dir_config calls. Geoffrey Young: generally, I would think that feature enhancements to Apache::FakeRequest would be preferred over another module that is essentially the same - a better FakeRequest has been on the ToDo list for some time now... any chance you can expand the existing Apache::FakeRequest and offer a patch? Sure I could try to patch Apache::FakeRequest, but I think the changes are quite fundamental. What to the mantainers of Apache::FakeRequest (or mod_perl) think of this? darren chamberlain: Don't know about the rest, but I saw Config::General, which will parse an Apache config file into a hash. Very useful, and very well done. I took a look at this module, and while it parses simple Apache config files correctly, it won't work with more complex ones. For example, it doesn't handle Include directivec (altough I submitted a patch to the author, so it will work with Apache Includes) and it can't parse VirtualHost Sections correctly. This questions of my initial posting are still unanswered: * Is it possible to subclass mod_perl or Apache::Request from outside of Apache (i.e. in a plain perl environment) ? * If not (which it seems to be), what would be the best way to implement all (more or less..) mod_perl methods and subclasses (Apache::Request et.al) ? Can one use the C code that mod_perl is based on? (Well, I guess I can't because I've never done any real C coding ...) ? -- D_omm O_xyderkes http://domm.zsi.at M_echanen M_asteuei
RFC: new module: Apache::FakeEnv
Hi! I am currently working on a module that generates a Fake Apache Request Object like Apache::FakeRequest does, but that also parses the Apache Configuration and enables the user to access values set with PerlSetVar (i.e. fake $r-dir_config). This Request Object can than be used in mod_perl modules, when running from the command line. I have a first (sort of) working version at: http://domm.zsi.at/source_code/Apache-FakeEnv.pm and the documentation at: http://domm.zsi.at/Apache-FakeEnv.html or embedded in Apache-FakeEnv.pm in pod-format This module has some limitations (see Section Limitations in the doc) that I would like to remove, but I'm not sure how, so ... * Is it possible to subclass mod_perl or Apache::Request from outside of Apache (i.e. in a plain perl environment) ? * If not (which it seems to be), what would be the best way to implement all (more or less..) mod_perl methods and subclasses (Apache::Request et.al) ? Can one use the C code that mod_perl is based on? (Well, I guess I can't because I've never done any real C coding ...) ? * Does a parser for the Apache Conifg Files exist somewhere (Parse::ReDescent or similar) or can one use the Apache Source Code or Apache itself to parse the config ? * Do you think that this module could be of interest to others (Should I put it on CPAN) ? Thanks for your attention ! -- D_omm O_xyderkes http://domm.zsi.at M_echanen M_asteuei
Re: RFC: new module: Apache::FakeEnv
Thomas Klausner ([EMAIL PROTECTED]) said something to this effect on 06/20/2001: Hi! I am currently working on a module that generates a Fake Apache Request Object like Apache::FakeRequest does, but that also parses the Apache Configuration and enables the user to access values set with PerlSetVar (i.e. fake $r-dir_config). *snip* * Does a parser for the Apache Conifg Files exist somewhere (Parse::ReDescent or similar) or can one use the Apache Source Code or Apache itself to parse the config ? Don't know about the rest, but I saw Config::General, which will parse an Apache config file into a hash. Very useful, and very well done. (darren) -- It is impossible to experience one's death objectively and still carry a tune. -- Woody Allen
