Hello,
NTI sure hope not! I second John Siracusa's post on this. Keep the HTML
NTgeneration well away from request parsing, please!
I personally am 100% in the camp of keeping HTML generation separate from
quest parsing, but I do recognize the advantage of having API level
compatibility between
On Tue, 25 Mar 2003, Stas Bekman wrote:
Lincoln Stein wrote:
How about making CGI.pm a subclass of $r? (optionally of course, by
dynamically changing @ISA), so instead of returning $q it'll return $r,
after re-blessing it.
Sounds interesting. What would be the advantage of that?
The
I suppose there might be name clashes, but I'll look into doing that.
Lincoln
On Monday 24 March 2003 07:08 pm, Stas Bekman wrote:
Lincoln Stein wrote:
How about making CGI.pm a subclass of $r? (optionally of course, by
dynamically changing @ISA), so instead of returning $q it'll return $r,
I can do this (changing the new() call to accept $r). My understanding is
that client code will need to be changed to take advantage of this, right?
The other issue is that it will only work with the OO form of CGI, which many
people (including myself) don't use.
I would prefer a more
Lincoln Stein wrote:
I can do this (changing the new() call to accept $r). My understanding is
that client code will need to be changed to take advantage of this, right?
That's correct. $r should be explicitly passed. However the CGI-side code
doesn't have to specific to mod_perl 2.0. CGI
Lincoln Stein wrote:
How about making CGI.pm a subclass of $r? (optionally of course, by
dynamically changing @ISA), so instead of returning $q it'll return $r,
after re-blessing it.
Sounds interesting. What would be the advantage of that?
The advantage is that
- you don't have to keep around
On 3/24/03 7:08 PM, Stas Bekman wrote:
In the future I can see someone extending Apache::Request to handle CGI.pm's
HTML generation in C, so the two could be replace each other.
I've always thought that HTML generation does not belong in CGI.pm, so I
don't see duplicating that functionality in
One more issue with CGI.pm and mp2, and other modules as well.
CGI.pm is using Apache-request. The setting/retrieval of the global request
record under threads is expensive, so the use of Apache-request is deprecated
in mp2.
If CGI.pm can be changed to optionally accept $r (as an argument to
