Randy Kobes wrote:
> On Tue, 6 Feb 2007, Issac Goldstand wrote:
>
>> Randy Kobes wrote:
>>> I'd be interested in any comments about these
>>> packages, including their names. CGI::Apache2::Ajax
>>> was tentatively chosen because, first of all, it only
>>> provides CGI.pm-compatible methods that the above two Ajax-related
>>> applications need, and also, CGI::Ajax
>>> expects the CGI object to satisfy
>>> ref($cgi) =~ /^CGI.*/
>>> Note though that, due to the nature of the APR::* modules
>>> used, CGI::Apache2::Ajax can also be used in a CGI
>>> environment. Thanks.
>>>
>>
>> Maybe I'm missing something, but why not autodetect Apache2::Request +
>> mod_perl2 presence and fallback to CGI if it doesn't work?
>>
>> Something like:
>>
>> if (exists $ENV{MOD_PERL_API_VERSION} &&
>> $ENV{MOD_PERL_API_VERSION} >= 2 &&
>> eval {require Apache2::Request}) {
>> ... mod_perl mode ...
>> } else {
>> ... CGI mode ...
>> }
>
> This type of check is done to see if one is running in a
> mod_perl environment, and if so, the Apache2::RequestRec
> object $r is used for things like setting the content-type
> header. For fetching parameters, however, Apache2::Request
> can also be used in a CGI environment, which may be
> useful for applications for which speed and/or memory
> is a concern. Thus, CGI::Apache2::Ajax relies completely
> on mod_perl2 and libapreq2, the intent being that it's
> up to the package needing these methods to use CGI if
> CGI::Apache2::Ajax isn't available (which Apache2-Ajax
> and Apache2-Autocomplete do).
>
Right, but I don't know of too many people using libapreq's perl glue
without mod_perl (and frankly wouldn't expect to at least until APR's
perl glue is separated from the rest of mod_perl)
