Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: On Mon, 22 May 2000, Peter Haworth wrote: In light of the non-dependency on mod_perl, the Apache::Request::Form name is also out. I'd still rather not use the CGI::Form name, in case there are any current users whose interface would change, which is a shame, because that seems like the most appropriate name. Erk, any ideas, or proof that no-one uses the existing CGI::Form? HTML::Form? :) Well, duh! Why didn't I think of that? Unfortunately though, HTML::Form already exists, and doesn't really do the same kind of thing. How about HTML::FormGen? I'd prefer to stick with one style of interface, to keep things small and simple. Named parameters as above seem most flexible, and allow for unexpected things like omMouseOver attributes to be added easily. I'm inclined to only allow method style calls, although I suppose there's nothing wrong with allowing people to import the methods and call them like this: print textfield($form,name = 'name', ...); agree all the way. Good. Anyone disagree? -- Peter Haworth [EMAIL PROTECTED] "The day Microsoft makes something that doesn't suck is the day they start making vacuums"
Re: RFC: Apache::Request::Forms (or something similar)
On Tue, 23 May 2000, Peter Haworth wrote: brian moseley wrote: On Mon, 22 May 2000, Peter Haworth wrote: In light of the non-dependency on mod_perl, the Apache::Request::Form name is also out. I'd still rather not use the CGI::Form name, in case there are any current users whose interface would change, which is a shame, because that seems like the most appropriate name. Erk, any ideas, or proof that no-one uses the existing CGI::Form? HTML::Form? :) Well, duh! Why didn't I think of that? Unfortunately though, HTML::Form already exists, and doesn't really do the same kind of thing. How about HTML::FormGen? HTML::Forms? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: RFC: Apache::Request::Forms (or something similar)
Peter Haworth wrote: brian moseley wrote: On Mon, 22 May 2000, Peter Haworth wrote: In light of the non-dependency on mod_perl, the Apache::Request::Form name is also out. I'd still rather not use the CGI::Form name, in case there are any current users whose interface would change, which is a shame, because that seems like the most appropriate name. Erk, any ideas, or proof that no-one uses the existing CGI::Form? HTML::Form? :) Well, duh! Why didn't I think of that? Unfortunately though, HTML::Form already exists, and doesn't really do the same kind of thing. How about HTML::FormGen? How about HTML::StickyForm(s)? I'd prefer to stick with one style of interface, to keep things small and simple. Named parameters as above seem most flexible, and allow for unexpected things like omMouseOver attributes to be added easily. I'm inclined to only allow method style calls, although I suppose there's nothing wrong with allowing people to import the methods and call them like this: print textfield($form,name = 'name', ...); agree all the way. Good. Anyone disagree? Nope. But I won't be calling it that way personally. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
"PH" == Peter Haworth [EMAIL PROTECTED] writes: HTML::Form? :) PH Well, duh! Why didn't I think of that? Unfortunately though, PH HTML::Form already exists, and doesn't really do the same kind of PH thing. How about HTML::FormGen? How 'bout HTML::StickyForms ? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
On Mon, 22 May 2000, Peter Haworth wrote: That's fairly likely. How about this kind of interface? my $form=CGI::Form-new($r); # Except for the name. See below # Or: my $form=CGI::Form-new($cgi); print $form-textfield(name = 'name', size = '60', default = 'Peter'); yup, looks good. In light of the non-dependency on mod_perl, the Apache::Request::Form name is also out. I'd still rather not use the CGI::Form name, in case there are any current users whose interface would change, which is a shame, because that seems like the most appropriate name. Erk, any ideas, or proof that no-one uses the existing CGI::Form? HTML::Form? :) I'd prefer to stick with one style of interface, to keep things small and simple. Named parameters as above seem most flexible, and allow for unexpected things like omMouseOver attributes to be added easily. I'm inclined to only allow method style calls, although I suppose there's nothing wrong with allowing people to import the methods and call them like this: print textfield($form,name = 'name', ...); agree all the way.
Re: RFC: Apache::Request::Forms (or something similar)
"PH" == Peter Haworth [EMAIL PROTECTED] writes: PH In light of the non-dependency on mod_perl, the PH Apache::Request::Form name is also out. I'd still rather not use PH the CGI::Form name, in case there are any current users whose PH interface would change, which is a shame, because that seems like PH the most appropriate name. Erk, any ideas, or proof that no-one PH uses the existing CGI::Form? Well, my older scripts use CGI::Form and CGI::Request along with CGI::Base. However, it is easy to work around. If your new version does not get a parameter, i.e., is called like "my $q = CGI::Form-new()" or "my $q = new CGI::Form" then instantiate a CGI::Request object for them and return that as your object handle, subclassing yourself to that object. I think you can do this at runtime... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Doug MacEachern wrote:
'ref_array' = sub {
my @a;
push @a, \($one, $two, $three);
my_print(@a);
},
aha. i knew i wasn't on crack. i just forgot an important
detail ;)
Re: RFC: Apache::Request::Forms (or something similar)
"Jeffrey W. Baker" wrote:
On Thu, 18 May 2000, brian moseley wrote:
On Thu, 18 May 2000, Autarch wrote:
pretty slow if you build a string using .= instead of using
smarter methods, like pushing strings onto an array and then
joining it.
You tried to sell me that when I was at CP, and I didn't buy it then
either. This is a benchmark of .= versus join. 50 20-byte strings
are joined:
Concat: 2 wallclock secs ( 1.34 usr + 0.27 sys = 1.61 CPU)
Join: 4 wallclock secs ( 3.63 usr + 0.19 sys = 3.82 CPU)
.= concatenation is way faster. Also, building a 50-element array in
Perl takes up vastly more memory than building a 1000-byte string.
The string and the Perl process together require an RSS of 11MB, while the
array and the Perl process eat an RSS of 51MB.
seems very odd. ".=" copies the string every time, and then
concatenates the new addition to the end. "join" may do something
internally like that, but i'd expect it to be optimized.
and so what?
that's all moot when it comes to generating html; you push strings
and then simply print:
@table = ();
loop {
@tr = ();
loop {
...
push(@row,"td",$data,"/td\n");
}
push(@table,"tr",@row,"/tr\n");
}
...
print(@table,$str,$val,$other);
(you could easily use more object-oriented CGI-like methods,
of course...)
no joining or concatenation needed.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Their is five errers in this sentance.
Re: Re: RFC: Apache::Request::Forms (or something similar)
: : On Wed, 17 May 2000, Peter Haworth wrote: : : Drew Taylor and I are about to write a subclass of Apache::Request which : includes form element generation methods, a la CGI.pm. The current : favourite : name is Apache::Request::Forms, but we'd like to know if anyone has a : better : one. : : The module is currently planned to be fairly bare-boned, only adding : form : element generation methods for methods which will benefit from : CGI.pm-style : sticky values, and the parameters these methods take are likely to be a : lot : more restricted than CGI.pm's (not difficult, really). However, this : could : change in the unlikely event that we get deluged with feature requests. : : personally, i'd like to see Apache::HTML for generating html, written in : c. something simple along the lines of HTML::AsSubs, then another class : to glues it and Apache::Request together that provides CGI.pm features, : like 'sticky forms'. but, i haven't given that much thought. I would as well Doug. I find that I only use Apache::Request and Apache::Cookie and that I sometimes need the functionality of CGI qw(:forms), but reframe from using it due to the bloatish issues. i.e it would be great to have such a thing as it would complement Apache::Request and Apache::Cookie. ps How are you getting on with the eagerly awaited mod_perl-dev-1.99 ? Just my 2 pence worth of a feature request Greg Cope (who should get his head round learning C one day)
New Module (was Re: RFC: Apache::Request::Forms (or something similar))
I have my own module for doing this job, sorry I missed many
posts of this thread but here is what I do:
- The target is automatically : add , update, select data
from a table reading data typed by the user.
- I didn't want to use the Apache api, so it even can be
used out of apache, so I called it : Persistence::DBI
thought I don't like this name much.
In This example I work with HTML::Mason, but as
I said before it can be used from whatever thingie, even
out of the web.
I'm using currently this in production sites and it saves
me a lot of work.
EXAMPLE OF CODE:
It's a little harder than this but you'll get the idea:
##customer.html###3
%init
# Make the object
my $customer=Persistence::DBI-open(
table = 'customers',
field_id = 'idCustomer'
field_data = \%ARGS
);
if (defined $_delete) {
$customer-delete;
}
/%init
## The html form is this way:
form
input type="text" name="name" value="% $customer-name %"
input type="text" name="phone" value="% $customer-phone %"
input type="submit" name="_save" value="save"
% if (defined $customer-idCustomer) {
input type="hidden" name="idCustomer"
value="% $customer-idCustomer %"
input type="submit" name="_delete" value="delete"
% }
/form
It works this way:
- if you supply the value of the id field it does a select
- if you supply all the fields but the id, it does an insert
- if you supply id and fields it does an update
Before calling the object you can check the values supplied
by the user to verify the values are correct.
If you modify values of the object it updates the data.
I'll accept name changes and I'll send the module to
whoever wants it. I checked it with MySQL and SQL server.
The module come with pods and it installs fine like any
other module.It needs the field_id be auto increment.
--
- frankie -
Re: RFC: Apache::Request::Forms (or something similar)
i do think that doug's separation of responsibilities into classes is the right one. your widget toolkit probably shouldn't be named Apache::HTML tho, unless it's actually using the apache api in some fashion. one reason i was thinking Apache::HTML is so we can use ap_pool for allocations.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Autarch wrote: C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. more like Perl is serious overkill :) SV's are BIG, notice the $unused variable and the B::TerseSize output (from Apache::Status) below, even before a string is copied into it, there's 48 bytes eaten. my $r = shift; $r-send_http_header; my $unused; my $string = "hi"; print $string; Totals: 1455 bytes | 23 OPs PADLIST summary: 0: undef [AV 116 bytes] MAX = 3 1: $r [RV52 bytes] 0x891b9b4 2: undef [GV81 bytes] 3: undef [NULL 24 bytes] 0x891ba44 4: undef [NULL 24 bytes] 0x891ba5c 5: $unused [NULL 48 bytes] 0x891ba50 6: $string [PV63 bytes] hi now let's look at CGI::start_html: Totals: 15595 bytes | 330 OPs PADLIST summary: 8:$title [PV78 bytes] Untitled Document 35: undef [PV 140 bytes] !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" 40: undef [PV56 bytes] HTMLHEADTITLE 46: undef [PV81 bytes] HTMLHEADTITLEUntitled Document/TITLE 48: undef [PV65 bytes] LINK REV=MADE HREF="mailto: 59: undef [PV49 bytes] BASE HREF=" 77: undef [PV48 bytes] NOSCRIPT 94: undef [PV49 bytes] /HEADBODY 96: undef [PV50 bytes] /HEADBODY 100: undef [PV45 bytes] /TITLE 101: undef [PV 199 bytes] !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" HTMLHEADTITLEUntitled Document/TITLE /HEADBODY i've omitted all but the string variables, notice the additional copies, which are a result of concatination. Perl copies *everything* and these copies add up to alot. this is why i would like to see an html generator written in c, it would result in a much smaller footprint, no matter what the Perl implementation may be.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, brian moseley wrote:
On Thu, 18 May 2000, Jeffrey W. Baker wrote:
.= concatenation is way faster
i don't have any results to back up my claim. therefore,
my words are eaten :)
i was convinced tho, even way back before you came to cp. i
wonder what convinced me!
that was probably me :) but, i don't recall suggesting join.
but i do recall pushing away from concat when print()-ing, this benchmark
also illustrates why i made Apache::print dereference references to
strings. 5.005_03 does seem todo better with the array benchmark than
5.006, oh well. there's tradeoffs both ways, i don't think there's a
clear winner.
Benchmark: timing 3 iterations of array, concat, ref_array...
array: 8 wallclock secs ( 6.90 usr + 0.27 sys = 7.17 CPU) @4184.10/s (n=3)
concat: 7 wallclock secs ( 5.98 usr + 0.16 sys = 6.14 CPU) @4885.99/s (n=3)
ref_array: 5 wallclock secs ( 4.59 usr + 0.16 sys = 4.75 CPU) @6315.79/s (n=3)
use Benchmark;
open my $fh, "/dev/null" or die;
my($one, $two, $three) = map { $_ x 4096 } 'a'..'c';
timethese(30_000, {
'ref_array' = sub {
my @a;
push @a, \($one, $two, $three);
my_print(@a);
},
'array' = sub {
my @a;
push @a, $one, $two, $three;
my_print(@a);
},
'concat' = sub {
my $s;
$s .= $one;
$s .= $two;
$s .= $three;
my_print($s);
},
});
sub my_print {
for (@_) {
print $fh ref($_) ? $$_ : $_;
}
}
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Gunther Birznieks wrote: eg I think there was a thread on this list way back about OO method calls versus direct package references... and people said that OO method calls have a lot of overhead, but I think in later versions of Perl, OO method call paths are cached(?) and so method calls no longer have the same overhead as they used to. there has always been a method cache, but even with that, methods are still a bit more expensive. the only improvement in 5.6.0 related to method calls (that i know of ) is that: $obj-method; #where method name is constant, know at compile time is now faster than: $obj-$method; #where $method isn't known until runtime
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Doug MacEachern wrote: C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. more like Perl is serious overkill :) SV's are BIG, notice the $unused variable and the B::TerseSize output (from Apache::Status) below, even before a string is copied into it, there's 48 bytes eaten. Well, my point was that the decision to code something in C should be done because it offers an overwhelming (orders of magnitude) improvement, preferably on more than one front (speed, memory, ease of maintenance (haha) ). Really, if you feel that Perl is too memory hungry and slow for even simple text output, then why use Perl at all? My bias is against C because I don't like it and I think it makes the module less accessible to people and therefore less likely to get improved by the community at large, and more likely to only get worked on by 1 person. -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Autarch wrote: Well, my point was that the decision to code something in C should be done because it offers an overwhelming (orders of magnitude) improvement, preferably on more than one front (speed, memory, ease of maintenance (haha) ). small savings here and there can add up to big savings in the end. did you look at the size of CGI::start_html? 16k. and that's a small subroutine, these things add up quick. Really, if you feel that Perl is too memory hungry and slow for even simple text output, then why use Perl at all? i never said that. i'm just trying to point out that it's worth considering the savings. My bias is against C because I don't like it and I think it makes the module less accessible to people and therefore less likely to get improved by the community at large, and more likely to only get worked on by 1 person. personally, i like to have generic things written in c, things that won't change much or at all after they are first implemented (not including bug shaking). e.g. Apache::Request. both c and Perl are great languages and blend very well together. both have pros and cons, i try to use the right combo of both to balance these out. c is smaller. c is faster. Perl is much easier to code than c, so i like to save it for things that are difficult to code. generating html is not difficult. is it really worth the time to implement this in c? i'm not convinced yet either, but it is worth thinking about. we need to consider these things if we want to see the Apache/Perl combo improve as a development platform. think big picture.
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Doug MacEachern wrote: personally, i like to have generic things written in c, things that won't change much or at all after they are first implemented (not including bug shaking). e.g. Apache::Request. both c and Perl are great languages and blend very well together. both have pros and cons, i try to use the right combo of both to balance these out. c is smaller. c is faster. Perl is much easier to code than c, so i like to save it for things that are difficult to code. generating html is not difficult. is it really worth the time to implement this in c? i'm not convinced yet either, but it is worth thinking about. we need to consider these things if we want to see the Apache/Perl combo improve as a development platform. think big picture. I would say that the bigger picture is definitely not generating HTML with functions - use templates or stylesheets. just my 2p. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: RFC: Apache::Request::Forms (or something similar)
"MS" == Matt Sergeant [EMAIL PROTECTED] writes: MS I would say that the bigger picture is definitely not generating HTML with MS functions - use templates or stylesheets. Templates (especially ones that let you iterate over arrays) are the way to go, in my book, for generating regular HTML. The only problem is with making a template that has sticky forms with non-text fields. Making a sticky menu select object ain't easy in templated-HTML, in my experience. I prefer to do forms (at least the menus and such) using functions for this reason. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, May 19, 2000 at 06:08:41PM +0100, Matt Sergeant wrote:
I would say that the bigger picture is definitely not generating HTML with
functions - use templates or stylesheets.
At the very moment, I have a problem to find arguments to persuate my
colleagues to accept this vision. Do you have some arguments that
could be used?
For example, some of our code currently looks like
$display_help = $q-get_preferences_from_db('display_help');
...
show_help('If you want to do that, do it this way ...')
if $display_help;
and show_help touches some global settings (updated per request) to see
if it should print the text with FONT SIZE="-1" or FONT
COLOR="grey", so the logic is in the functions (or methods) that are
called throughout the code or the script/handler.
I'd much better just do something like
push @out, 'HELPIf you want to do that, do it this way .../HELP';
or even generate it with template, and then postprocess this with
stylesheet, and change the color setting or remove the help text
completely, if the user has the $display_help = 0 set because he's an
advanced user. The main objection I hear to this is that you'd need to
parse and substitute something that you could have gotten right in the
first place, and you can do the design changes in the functions as
you'd do in the stylesheet.
Can you help me with some points that I could use to persuate
templates and/or stylesheet for this application?
--
Honza Pazdziora | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
Re: RFC: Apache::Request::Forms (or something similar)
Matt, All I'm looking for is the fastest way to print sticky form elements. I already use HTML::Template for the page templating engine (and it works very well!). I need to take a look at CGI v.3 beta to see if it answers some of my concerns about memory usage. Matt Sergeant wrote: On Fri, 19 May 2000, Doug MacEachern wrote: personally, i like to have generic things written in c, things that won't change much or at all after they are first implemented (not including bug shaking). e.g. Apache::Request. both c and Perl are great languages and blend very well together. both have pros and cons, i try to use the right combo of both to balance these out. c is smaller. c is faster. Perl is much easier to code than c, so i like to save it for things that are difficult to code. generating html is not difficult. is it really worth the time to implement this in c? i'm not convinced yet either, but it is worth thinking about. we need to consider these things if we want to see the Apache/Perl combo improve as a development platform. think big picture. I would say that the bigger picture is definitely not generating HTML with functions - use templates or stylesheets. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Matt Sergeant wrote: Damn - forgot smiley. Sorry :-) doh. your reponse combined with my jetlag == foncusion :-)
Re: RFC: Apache::Request::Forms (or something similar)
Doug MacEachern wrote: personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought. Well, I wouldn't mind doing it in C (since the raison d'etre is to be as absolutely fast lean as possible), but I don't know C. :-( -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Drew Taylor wrote: Doug MacEachern wrote: personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought. Well, I wouldn't mind doing it in C (since the raison d'etre is to be as absolutely fast lean as possible), but I don't know C. :-( i suggest that most applications are going to find their bottlenecks somewhere besides simple html widget generation. it should be extremely straightforward, if maybe a bit time consuming, to write very simple, vanilla perl widget routines. that avoid the bloatfest of CGI.pm and that don't use the most esoteric features of perl like hTML::AsSubs. i think we all know that form controls are the important widgets. i challenge anyone to prove to me that you need a routine to wrap your string in b tags. i do think that doug's separation of responsibilities into classes is the right one. your widget toolkit probably shouldn't be named Apache::HTML tho, unless it's actually using the apache api in some fashion.
Re: RFC: Apache::Request::Forms (or something similar)
Drew Taylor wrote: Doug MacEachern wrote: personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought. Well, I wouldn't mind doing it in C (since the raison d'etre is to be as absolutely fast lean as possible), but I don't know C. :-( I'd have no problem writing it in C, but I'm not convinced that the generality is helpful with something intended to be small and fast. That wouldn't stop us from rewriting the internals to a hypothetical Apache::HTML at some point in the future, though. I'm getting more confident about calling it Apache::Request::Form (no "s", for name similarity with CGI::Form) now. It is dependent on Apache::Request, after all, and reusing the CGI::Form name makes it look more general than it really is, not to mention any strange version skew effects CPAN.pm might introduce when people try to install things. -- Peter Haworth [EMAIL PROTECTED] "Where a computer like the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and weigh only 1 1/2 tons." -- Popular Mechanics, March 1949
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Peter Haworth wrote: I'm getting more confident about calling it Apache::Request::Form (no "s", for name similarity with CGI::Form) now. It is dependent on Apache::Request, after all, and reusing the CGI::Form name makes it look more general than it really is, not to mention any strange version skew effects CPAN.pm might introduce when people try to install things. are you still planning to subclass Apache::Request? why? what benefit do you get, if the only method from Apache::Request you need is param()? unnecessary coupling..
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote:
On Thu, 18 May 2000, Peter Haworth wrote:
I'm getting more confident about calling it
Apache::Request::Form (no "s", for name similarity with
CGI::Form) now. It is dependent on Apache::Request,
after all, and reusing the CGI::Form name makes it look
more general than it really is, not to mention any
strange version skew effects CPAN.pm might introduce
when people try to install things.
are you still planning to subclass Apache::Request? why?
what benefit do you get, if the only method from
Apache::Request you need is param()? unnecessary coupling..
I personally have code that puts a CGI.pm object in the object ($self),
which is then used for both HTML generation AND fetching params AND
cookies.
For example, I have lines like 'my $val = $self-{CGI}-param('blah')'
as well as 'my $form = $self-{CGI}-popup_menu(-name='blah', ...)'.
The effect is to emulate CGI.pm, while being leaner simpler.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote:
On Thu, 18 May 2000, Drew Taylor wrote:
I personally have code that puts a CGI.pm object in the
object ($self), which is then used for both HTML
generation AND fetching params AND cookies.
For example, I have lines like 'my $val =
$self-{CGI}-param('blah')' as well as 'my $form =
$self-{CGI}-popup_menu(-name='blah', ...)'. The
effect is to emulate CGI.pm, while being leaner
simpler.
am i missing something..? you're actually /using/ CGI.pm
inside your new module?
No, my /CURRENT/ setup uses CGI.pm. I want to eliminate it entirely in
this new module, while not having to change any of my existing
application code. I would like to not change any lines like the ones
above when switching to the new module.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Doug MacEachern wrote: personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought. C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. I really think the goal should be to make Apache::Request integrated into the new CGI module (or vice versa, depends on how you look at it). -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Drew Taylor wrote: No, my /CURRENT/ setup uses CGI.pm. I want to eliminate it entirely in this new module, while not having to change any of my existing application code. I would like to not change any lines like the ones above when switching to the new module. ah, ok. bumming. i suggest that instead of subclassing Apache::Request, you write the following set of classes: 1) html widget class 2) sticky forms class - use html widget class, take $r or $q as param 3) "wrapper" class - gives you the CGI.pm interface, uses sticky forms class, takes $r or $q as param this would give us the best of both worlds: you get a plug-in replacement for CGI.pm, we get a set of classes that aren't tightly coupled to each other. by keeping the sticky forms class and wrapper class separate, you allow people who just want sticky forms to get that, and people who want the whole ungodly CGI.pm interface to get that.
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: i suggest that instead of subclassing Apache::Request, you write the following set of classes: 1) html widget class 2) sticky forms class - use html widget class, take $r or $q as param 3) "wrapper" class - gives you the CGI.pm interface, uses sticky forms class, takes $r or $q as param What do you define the difference to be between #1 and #2? All I need is sticky forms - primarily the popup_menu(). If HTML widgets are b(), td(), etc, then we didn't plan on creating those. Forms is the main point of this module. this would give us the best of both worlds: you get a plug-in replacement for CGI.pm, we get a set of classes that aren't tightly coupled to each other. by keeping the sticky forms class and wrapper class separate, you allow people who just want sticky forms to get that, and people who want the whole ungodly CGI.pm interface to get that. Now that makes sense, in that it is more generic in nature. After all, I would hope that this will be a useful module to many people, not just Peter and I. When we get some time, Peter and I should sit down and try to come up with a v.01 API. Of course, all thoughts would be welcome. The whole module is beginning to coalesce more in my mind after all this discussion. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: On Thu, 18 May 2000, Autarch wrote: C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. pretty slow if you build a string using .= instead of using smarter methods, like pushing strings onto an array and then joining it. I didn't know joining array elements was faster. How much slower is using the .= operator rather than join "\n", @array? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Drew Taylor wrote:
What do you define the difference to be between #1 and
#2? All I need is sticky forms - primarily the
popup_menu(). If HTML widgets are b(), td(), etc, then
we didn't plan on creating those. Forms is the main
point of this module.
well the function that creates a popup menu is different
than the function that enables stickiness for a particular
instance of a popup menu. how's this for pseudo code:
--
package FormWidget;
sub popup_menu
{
# generate the html for a popup menu
}
package StickyForm;
my $pm1 = FormWidget::popup_menu('pm1', $r-param('pm1'));
my $pm2 = FormWidget::popup_menu('pm2', $r-param('pm2'));
--
obviously there is a lot more to making forms sticky than
that. but you get the gist of the general separation of
responsibilities.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, brian moseley wrote:
i suggest that instead of subclassing Apache::Request, you
write the following set of classes:
1) html widget class
2) sticky forms class - use html widget class, take $r or $q
as param
3) "wrapper" class - gives you the CGI.pm interface, uses
sticky forms class, takes $r or $q as param
this would give us the best of both worlds: you get a
plug-in replacement for CGI.pm, we get a set of classes that
aren't tightly coupled to each other. by keeping the sticky
forms class and wrapper class separate, you allow people who
just want sticky forms to get that, and people who want the
whole ungodly CGI.pm interface to get that.
#1 exists in the new CGI
#2 could be integrated with the new CGI with some amount of effort (though
I doubt it would be huge). Right now the sticky forms aspect works by
having the form generating object call $self-param to set defaults. If
this were changed to call $self-{state}-param and have what's in state
be either a CGI or Apache::Request object you'd be all set.
#3 is the new CGI
I really don't think we need yet another module doing what CGI does. The
people who've worked on the new version have done a very good job of
addressing the memory and speed concerns people had about the current
monolothic version. I think its much better to extend their work than to
redo it.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, brian moseley wrote:
On Thu, 18 May 2000, Autarch wrote:
C seems like serious overkill for something to simply
generate plain text output. How slow is making a string
in perl compared to doing it in C? I can't imagine
there's to much of a difference.
pretty slow if you build a string using .= instead of using
smarter methods, like pushing strings onto an array and then
joining it.
You tried to sell me that when I was at CP, and I didn't buy it then
either. This is a benchmark of .= versus join. 50 20-byte strings
are joined:
Concat: 2 wallclock secs ( 1.34 usr + 0.27 sys = 1.61 CPU)
Join: 4 wallclock secs ( 3.63 usr + 0.19 sys = 3.82 CPU)
.= concatenation is way faster. Also, building a 50-element array in
Perl takes up vastly more memory than building a 1000-byte string.
The string and the Perl process together require an RSS of 11MB, while the
array and the Perl process eat an RSS of 51MB.
Here is the benchmark program used:
my $iter = shift;
sub concat {
my $this;
for (my $i = 0; $i $iter; $i++) {
$this .= 'A'x20;
}
}
sub arrayjoin {
my @this;
for (my $i = 0; $i $iter; $i++) {
push(@this, 'A'x20);
}
join('', @this);
}
timethese(1, { 'Concat' = \concat, 'Join' = \arrayjoin });
The system was an Intel Pentium III 500 MHz with 128 MB of RAM and Linux
2.2.15. Swap was turned off.
-jwb
Re: RFC: Apache::Request::Forms (or something similar)
Autarch wrote: I really don't think we need yet another module doing what CGI does. The people who've worked on the new version have done a very good job of addressing the memory and speed concerns people had about the current monolothic version. I think its much better to extend their work than to redo it. Based on the comment on CGI.pm v3, I guess a look-see at the new code is required. As you say, why re-implement the wheel? I'm primarily concerned with memory usage, and speed secondary. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Jeffrey W. Baker wrote: .= concatenation is way faster i don't have any results to back up my claim. therefore, my words are eaten :) i was convinced tho, even way back before you came to cp. i wonder what convinced me!
Re: RFC: Apache::Request::Forms (or something similar)
At 10:53 AM 5/18/00 -0700, brian moseley wrote: On Thu, 18 May 2000, Jeffrey W. Baker wrote: .= concatenation is way faster i don't have any results to back up my claim. therefore, my words are eaten :) i was convinced tho, even way back before you came to cp. i wonder what convinced me! You never know. Perl comes up with smarter and smarter optimizations all the time. Perhaps if the same benchmark were run on Perl 5.003 you would get a different result. eg I think there was a thread on this list way back about OO method calls versus direct package references... and people said that OO method calls have a lot of overhead, but I think in later versions of Perl, OO method call paths are cached(?) and so method calls no longer have the same overhead as they used to. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Drew Taylor wrote:
I personally have code that puts a CGI.pm object in the
object ($self), which is then used for both HTML
generation AND fetching params AND cookies.
For example, I have lines like 'my $val =
$self-{CGI}-param('blah')' as well as 'my $form =
$self-{CGI}-popup_menu(-name='blah', ...)'. The
effect is to emulate CGI.pm, while being leaner
simpler.
am i missing something..? you're actually /using/ CGI.pm
inside your new module?
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. There's going to be a new version of CGI some time in the future which will allow you to only use the parts of it you need without all the memory bloat. There's an alpha on Lincoln's page at http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz With this and Apache::Request I'm not sure I see the need for what you guys are working on. -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC: Apache::Request::Forms (or something similar)
If you are considering writing subclasses that do similar things to CGI.pm, you might consider looking at CGI.pm 3.0 as the various features (eg HTML generation) are more broken out... And then the two would run more parallel to each other. At 03:30 PM 5/17/00 +0100, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. The module is currently planned to be fairly bare-boned, only adding form element generation methods for methods which will benefit from CGI.pm-style sticky values, and the parameters these methods take are likely to be a lot more restricted than CGI.pm's (not difficult, really). However, this could change in the unlikely event that we get deluged with feature requests. -- Peter Haworth [EMAIL PROTECTED] "We're sorry. The brain you have mailed has been disconnected or is no longer in service. Please re-check the address and send your message again. If you feel you have reached this recording in error, JUST STOP CREATING EVIL PUNCTUATION OPERATORS, SO CHIP'S BRAIN WILL STOP EXPLODING. Thank you." -- Chip Salzenberg
Re: RFC: Apache::Request::Forms (or something similar)
Autarch wrote: On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. There's going to be a new version of CGI some time in the future which will allow you to only use the parts of it you need without all the memory bloat. There's an alpha on Lincoln's page at http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz With this and Apache::Request I'm not sure I see the need for what you guys are working on. Without looking at the new CGI.pm, I'd say that the benefit of our new module would be that it's targetted specifically at mod_perl, so it should hopefully be smaller, and ideally it would be faster. The non-backwards compatible nature of the new interface also allows us to cut down on some of the overhead of CGI.pm's need to figure out which calling style is used. -- Peter Haworth [EMAIL PROTECTED] "Who needs horror movies when we have Microsoft"? -- Christine Comaford, PC Week, 27/9/95
Re: RFC: Apache::Request::Forms (or something similar)
"PH" == Peter Haworth [EMAIL PROTECTED] writes: PH Drew Taylor and I are about to write a subclass of Apache::Request PH which includes form element generation methods, a la CGI.pm. The PH current favourite name is Apache::Request::Forms, but we'd like to PH know if anyone has a better one. Have you looked at CGI::Form that already exists? It would be a good basis. Currently, it is based on CGI::Request but should be able to use Apache::Request one would expect. I think the name CGI::Form is appropriate, since the forms are part of the CGI protocol, not anything mod_perl or Apache sepecific. CGI::Form seems to be an abandoned module, so I'm sure you can get permission to adopt it and extend it. That's my personal recommendation. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
Autarch wrote: On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. There's going to be a new version of CGI some time in the future which will allow you to only use the parts of it you need without all the memory bloat. There's an alpha on Lincoln's page at http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz With this and Apache::Request I'm not sure I see the need for what you guys are working on. 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. If anyone is interested, here are the form elements we're currently looking at inplementing: textfield() textarea() passwordfield() checkbox() checkbox_group() radio_group() popup_menu() scrolling_list() 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. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
Vivek Khera wrote: Have you looked at CGI::Form that already exists? It would be a good basis. Currently, it is based on CGI::Request but should be able to use Apache::Request one would expect. Actually, I have briefly looked at this module and looked no more when I realized it was no longer being maintained. I'll take a look at the code and see if it's workable to our goals. It would be really nice to have a starting point, no matter how rough. I had also considered looking at CGI.pm and seeing how it does things internally. Is it "moral" to use code from one module in another if they are both released under the same license? I think the name CGI::Form is appropriate, since the forms are part of the CGI protocol, not anything mod_perl or Apache sepecific. CGI::Form seems to be an abandoned module, so I'm sure you can get permission to adopt it and extend it. Well, in our case we are looking to make it mod_perl specific. See my previous post for my reasoning why. The name is not terribly important to me, but the Apache:: namespace seemed appropriate for it's mod_perl specificness (is that a word?). -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: peter: i question why you want to subclass Apache::Request, rather than provide a helper class that maybe maintains a reference to an Apache::Request object, or some other weaker type of relationship. That is an interesting point Brian. What I would like is a single object I can use to get form params OR generate HTML, ala CGI.pm, but mod_perl specific for speed reasons. The idea is to have as small a memory footprint as possible, using the mod_perl API only. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
"bm" == brian moseley [EMAIL PROTECTED] writes: bm actually forms are specified in HTML, not CGI. Ok... if you say so. bm consider writing your forms library to depend on an bm interface, not a specific class, so that users can provide bm either a CGI object or an Apache::Request object. perhaps bm the only interface you need is $obj-param? This would make a great case for using CGI::Form then... That seems to be the only thing it relies on from my quick glance at the code.
Re: RFC: Apache::Request::Forms (or something similar)
"DT" == Drew Taylor [EMAIL PROTECTED] writes: I think the name CGI::Form is appropriate, since the forms are part of DT Well, in our case we are looking to make it mod_perl specific. See my Right... But if your interface only relies on calling $x-param() then it can be based on any CGI-ish module that provides that interface. I think this will be a big win. I can't imagine any other interface you'd need to create this module, and that's only for the stickyness of it. As for borrowing code, go for it, but be sure to attribute it in both the code and the documentation. Most modules are distributed under the Perl license, which is quite liberal. I'd suggest making the calling convention require named parameters and require it to be an object rather than a function call interface.
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Drew Taylor wrote: That is an interesting point Brian. What I would like is a single object I can use to get form params OR generate HTML, ala CGI.pm, but mod_perl specific for speed reasons. The idea is to have as small a memory footprint as possible, using the mod_perl API only. what part of the mod_perl api are you going to actually use? with the list of widgets you sent earlier, i'm hard pressed to see where anything other than $obj-param will be useful to you. i don't see where you would get any benefit from being "mod_perl specific".
Re: RFC: Apache::Request::Forms (or something similar)
At 11:32 AM 5/17/00 -0400, Drew Taylor wrote: Vivek Khera wrote: Have you looked at CGI::Form that already exists? It would be a good basis. Currently, it is based on CGI::Request but should be able to use Apache::Request one would expect. Actually, I have briefly looked at this module and looked no more when I realized it was no longer being maintained. I'll take a look at the code and see if it's workable to our goals. It would be really nice to have a starting point, no matter how rough. I had also considered looking at CGI.pm and seeing how it does things internally. Is it "moral" to use code from one module in another if they are both released under the same license? "moral" or "legal". In my book it is moral to take code snippets as long as due credit is given for Open Source. At the level of code snippets, that's really how we all learn programming anyway. I would be hard pressed to find anyone that writes truly original code (unless they make it look really weird like the obfuscation contests!). That is usually what the Open Source licenses request anyway. If people didn't want you to pervert the code, they wouldn't have made it open source. I think the name CGI::Form is appropriate, since the forms are part of the CGI protocol, not anything mod_perl or Apache sepecific. CGI::Form seems to be an abandoned module, so I'm sure you can get permission to adopt it and extend it. Well, in our case we are looking to make it mod_perl specific. See my previous post for my reasoning why. The name is not terribly important to me, but the Apache:: namespace seemed appropriate for it's mod_perl specificness (is that a word?). You stated why but it seemed a bit vague. You mention performance. What about CGI.pm's HTML generation methods is too slow that you will improve using mod_perl specific features? And why is the API itself a reason for it being slow that you have to make the API itself different from CGI.pm?
Re: RFC: Apache::Request::Forms (or something similar)
At 11:25 AM 5/17/00 -0400, you wrote: Autarch wrote: On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. There's going to be a new version of CGI some time in the future which will allow you to only use the parts of it you need without all the memory bloat. There's an alpha on Lincoln's page at http://stein.cshl.org/WWW/software/CGI/CGI.pm-3.01tar.gz With this and Apache::Request I'm not sure I see the need for what you guys are working on. 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. If anyone is interested, here are the form elements we're currently looking at inplementing: 1) It will be released when there are enough people banging on it and submitting comments. Hence it is in alpha because the API could change in the future, BUT it is wanting for people to help test. 2) The interface for CGI.pm 3.x is that the monolithic pre-3.0 CGI.pm was broken into a well defined object hierarchy. Otherwise, I believe it is basically the same API.
Re: RFC: Apache::Request::Forms (or something similar)
Gunther Birznieks wrote: You stated why but it seemed a bit vague. You mention performance. What about CGI.pm's HTML generation methods is too slow that you will improve using mod_perl specific features? And why is the API itself a reason for it being slow that you have to make the API itself different from CGI.pm? It's not CGI.pm's API that I want to change, I just want to make it leaner. It sounds like version 3 would accomplish this, so perhaps this is all a waste of everyone's time. Let me restate, I have no problem with CGI's HTML generation methods. I would just like something smaller, as far as memory usage goes. :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
brian moseley wrote: what part of the mod_perl api are you going to actually use? with the list of widgets you sent earlier, i'm hard pressed to see where anything other than $obj-param will be useful to you. i don't see where you would get any benefit from being "mod_perl specific". See my reply to Gunther. Basically, I want a leaner (less memory usage) module to use for HTML generation. I guess I was wrong to say that using "mod_perl specific" API calls would make it faster. Perhaps one could say it's "faster" based on the fact that it will use Apache::Request (written in C as we all know), and it is my understanding that Apache::Request is faster that CGI.pm. It sounds like this might all be moot anyway once CGI.pm v 3 is released. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: RFC: Apache::Request::Forms (or something similar)
On Wed, 17 May 2000, Peter Haworth wrote: Drew Taylor and I are about to write a subclass of Apache::Request which includes form element generation methods, a la CGI.pm. The current favourite name is Apache::Request::Forms, but we'd like to know if anyone has a better one. The module is currently planned to be fairly bare-boned, only adding form element generation methods for methods which will benefit from CGI.pm-style sticky values, and the parameters these methods take are likely to be a lot more restricted than CGI.pm's (not difficult, really). However, this could change in the unlikely event that we get deluged with feature requests. personally, i'd like to see Apache::HTML for generating html, written in c. something simple along the lines of HTML::AsSubs, then another class to glues it and Apache::Request together that provides CGI.pm features, like 'sticky forms'. but, i haven't given that much thought.
