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-
modperl&m=98719810927157&w=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
