On Wed, 17 May 2000, Drew Taylor wrote:
> Well, my question is 1). when is it going to be released and 2) what is
> the interface? Our aim is to produce a much smaller module, intended to
> be used only under mod_perl, with a much more restricted set of methods.
1. I dunno
2. Like the existing CGI.pm
The overhead of the function/object duality appears to have been somewhat
minimized because looking at the code I don't see any calls to
(self_or_object) or whatever it used to be.
> Our reasoning behind this is very simple. We need (and in fact I rely
> HEAVILYon ) a few of the HTML generation features in CGI.pm, namely
> popup_menu for myself. I would like to convert my sites to pure perl
> handlers, and drop CGI.pm all together. But I can't do this until I have
> a drop-in replacement, hence this project.
I really think what you want to make is not really needed as the new
CGI.pm will do what you want and will have a reasonably reduced memory and
speed overhead. One thing that could be done to improve this would be to
break the currently fairly large CGI::Object::Html class into several
smaller classes (::Forms ::Tables ::??). Then if you restrict yourself to
using methods from only one you save even more.
You've mentioned several times wanting something mod_perl specific but I
really don't see how HTML output is mod_perl specific. You already have
mod_perl specific input with Apache::Request.
I just took a look at the new CGI code and it looks like it needs an
object that has a param method (it uses $self) for some of the output
methods. Perhaps you could work with the authors to make this interface
rather than class dependent so that an Apache::Request object could fill
this role.
I think this is the best way to go. I think you guys have a need which
the new CGI will partially fill and the best way to fully fulfill it is to
work on CGI.pm to make it better rather than creating yet another HTML/CGI
module.
-dave
/*==================
www.urth.org
We await the New Sun
==================*/
