Hello,
NT>I sure hope not! I second John Siracusa's post on this. Keep the HTML
NT>generation 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
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 retur
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
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 tw
> 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?
Lincoln
>
> > The other issue is that it will only work with the OO f
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 should
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 transpare