You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Peter Haworth <pm...@edison.ioppublishing.com> on 2000/05/17 16:30:44 UTC
RFC: Apache::Request::Forms (or something similar)
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 pmh@edison.ioppublishing.com
"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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Gunther Birznieks <gu...@extropia.com>.
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: Segfault on DBI->connect
Posted by "Richard L. Goerwitz" <ri...@catlin.cis.brown.edu>.
Many of us have been experiencing segfaults on DBI->connect when using the
DBD-mysql
drivers.
I wonder if anyone has found a solution.
I've appended a pretty comprehensive overview of the problem below.
Problem description: Child Apache process segfaults on DBI->connect with
Apache
1.3.12 and Msql-Mysql-modules-1.22{11,12,13,14} (maybe other versions,
too). This
happens with mod_perl versions 1.22 through 1.24. I happen to be running
RedHat
6.1 with egcs-2.91.66, but I've built everything (from Perl to Apache) from
scratch.
Anyway, the point of failure has been found: the MySQL mysql_real_connect()
routine called by Msql-Mysql-modules-1.22{11-14} gets passed a NULL first
arg.
So far nobody has figured out what is going on here, and why this problem
has only now started to crop up. It seemed to appear when I upgraded
mod_perl
to 1.22 and Apache to 1.3.12.
Here's one of my low-level traces. Farther below I offer a DBI->trace(9)
trace,
which shows what's going on from Perl/DBI/DBD's point of view.
> Running Apache with a -X argument yields the following backtrace when my
> mod_perl module does a DBI->connect (str, username, passwd, { options }).
> Note the null mysql argument ------------
> |
> v
> #0 0x80ef5b7 in mysql_real_connect (mysql=0x0,
> host=0x8a99db8 "catlin.cis.brown.edu", user=0x8a9b550 "proxystuff",
> passwd=0x8a9b568 "Kui0-,12!", db=0x8a99e40 "proxysession", port=3306,
> unix_socket=0x0, client_flag=0) at libmysql.c:1125
> #1 0x402d01fd in mysql_dr_connect ()
> from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> #2 0x402d0540 in _MyLogin ()
> from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
I really don't know how the null first argument is getting passed to
mysql_real_connect.
Here's a DBI->trace (9) of what's going on. I confess that I don't
understand
most of this output (which comes from my Apache error log file):
> DBI 1.13-nothread dispatch trace level set to 9
> -> DBI->Apache::DBI::connect(dbi:mysql:database=proxysession;host=catlin.cis.brown.edu;port=3306, proxystuff, Kui0-,12!)
> -> DBI->install_driver(mysql) for perl=5.00503 pid=14122 ruid=99 euid=99
> install_driver: DBD::mysql loaded (version 2.0414)
> New DBI::dr (for DBD::mysql::dr, parent=, id=)
> dbih_setup_handle(DBI::dr=HASH(0x858a0e8)=>DBI::dr=HASH(0x8930414), DBD::mysql::dr, 0, Null!)
> dbih_make_com(Null!, DBD::mysql::dr, 84)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), Err, Null!) SCALAR(0x89259cc) (already defined)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), State, Null!) SCALAR(0x858a3ac) (already defined)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), Errstr, Null!) SCALAR(0x89259e4) (already defined)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), Handlers, Null!) ARRAY(0x89304c8) (already defined)
> dbih_setup_attrib(DBI::dr=HASH(0x8930414), Debug, Null!) 0 (already defined) <- install_driver= DBI::dr=HASH(0x858a0e8)
> >> FETCH DISPATCH (DBI::dr=HASH(0x8930414) rc2/1 @2 g0 a866b270) at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 64.
> <- FETCH= 'mysql' ('Name' from cache) at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 64.
> >> connect DISPATCH (DBI::dr=HASH(0x858a0e8) rc1/5 @5 g0 a866b288) at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 120.
> -> connect for DBD::mysql::dr (DBI::dr=HASH(0x858a0e8)~0x8930414 'database=proxysession;host=catlin.cis.brown.edu;port=3306' 'proxystuff' 'pKui0-,12!' HASH(0x892441c))
> New DBI::db (for DBD::mysql::db, parent=DBI::dr=HASH(0x8930414), id=HASH(0x8930450))
> dbih_setup_handle(DBI::db=HASH(0x89304a4)=>DBI::db=HASH(0x893a058), DBD::mysql::db, 8587d60, HASH(0x8930450))
> dbih_make_com(DBI::dr=HASH(0x8930414), DBD::mysql::db, 520)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), Err, DBI::dr=HASH(0x8930414)) SCALAR(0x89259cc) (already defined)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), State, DBI::dr=HASH(0x8930414)) SCALAR(0x858a3ac) (already defined)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), Errstr, DBI::dr=HASH(0x8930414)) SCALAR(0x89259e4) (already defined)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), Handlers, DBI::dr=HASH(0x8930414)) ARRAY(0x89304c8) (already defined)
> dbih_setup_attrib(DBI::db=HASH(0x893a058), Debug, DBI::dr=HASH(0x8930414)) 0 (already defined)
> imp_dbh->connect: dsn = database=proxysession;host=catlin.cis.brown.edu;port=3306, uid = proxystuff, pwd = Kui0-,12!
> imp_dbh->MyLogin: dbname = proxysession, uid = proxystuff, pwd = Kui0-,12!,host = catlin.cis.brown.edu, port = 3306
> imp_dbh->MyConnect: host = catlin.cis.brown.edu, port = 3306, uid = proxystuff, pwd = Kui0-,12!
> imp_dbh->MyConnect: client_flags = 0
> [Wed May 17 11:17:29 2000] [notice] child pid 14122 exit signal Segmentation fault (11)
--
Richard Goerwitz Richard_Goerwitz@Brown.EDU
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "DT" == Drew Taylor <dt...@vialogix.com> 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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "bm" == brian moseley <ix...@maz.org> 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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by brian moseley <ix...@maz.org>.
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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "PH" == Peter Haworth <pm...@edison.ioppublishing.com> 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: khera@kciLink.com Rockville, MD +1-301-545-6996
GPG & MIME spoken here http://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Peter Haworth <pm...@edison.ioppublishing.com>.
Vivek Khera wrote:
> >>>>> "PH" == Peter Haworth <pm...@edison.ioppublishing.com> 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 ?
OK, that's two votes, and I like it as well.
HTML::StickyForms (or possibly HTML::StickyForm) it is then.
--
Peter Haworth pmh@edison.ioppublishing.com
A host is a host from coast to coast
& no one will talk to a host that's close
Unless the host (that isn't close)
is busy, hung or dead
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "PH" == Peter Haworth <pm...@edison.ioppublishing.com> 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: khera@kciLink.com Rockville, MD +1-301-545-6996
GPG & MIME spoken here http://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Matt Sergeant <ma...@sergeant.org>.
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)
Posted by Peter Haworth <pm...@edison.ioppublishing.com>.
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 pmh@edison.ioppublishing.com
"The day Microsoft makes something that doesn't suck
is the day they start making vacuums"
Re: RFC: Apache::Request::Forms (or something similar)
Posted by brian moseley <ix...@maz.org>.
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)
Posted by Peter Haworth <pm...@edison.ioppublishing.com>.
brian moseley wrote:
> On Wed, 17 May 2000, Vivek Khera wrote:
>
> > 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.
>
> actually forms are specified in HTML, not CGI.
>
> 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.
Thanks to all the discussion, I'm coming round to the helper class idea. It was
really only that I hadn't thought of it myself, and that I thought I'd found an
omission in Apache::Request which didn't exist, which I could fix at the same
time.
> consider writing your forms library to depend on an
> interface, not a specific class, so that users can provide
> either a CGI object or an Apache::Request object. perhaps
> the only interface you need is $obj->param?
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');
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?
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', ...);
--
Peter Haworth pmh@edison.ioppublishing.com
"The Feynman Problem 1) Write down the problem.
Solving Algorithm: 2) Think real hard.
3) Write down the answer."
Re: RFC: Apache::Request::Forms (or something similar)
Posted by brian moseley <ix...@maz.org>.
On Wed, 17 May 2000, Vivek Khera wrote:
> 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.
actually forms are specified in HTML, not CGI.
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.
consider writing your forms library to depend on an
interface, not a specific class, so that users can provide
either a CGI object or an Apache::Request object. perhaps
the only interface you need is $obj->param?
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "PH" == Peter Haworth <pm...@edison.ioppublishing.com> 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: khera@kciLink.com Rockville, MD +1-301-545-6996
GPG & MIME spoken here http://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Doug MacEachern <do...@covalent.net>.
> 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)
Posted by brian moseley <ix...@maz.org>.
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.
New Module (was Re: RFC: Apache::Request::Forms (or something similar))
Posted by Francesc Guasch <fr...@etsetb.upc.es>.
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)
Posted by Drew Taylor <dt...@vialogix.com>.
brian moseley wrote:
> 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:
In my mind, they are one and the same. The "sticky" part is the
"-default=>$value" part of the method call isn't it? I don't create
forms elements with out specifying the default value.
--
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)
Posted by brian moseley <ix...@maz.org>.
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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Autarch <au...@urth.org>.
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)
Posted by brian moseley <ix...@maz.org>.
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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by brian moseley <ix...@maz.org>.
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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by brian moseley <ix...@maz.org>.
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)
Posted by Peter Haworth <pm...@edison.ioppublishing.com>.
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 pmh@edison.ioppublishing.com
"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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Vivek Khera <kh...@kciLink.com>.
>>>>> "MS" == Matt Sergeant <ma...@sergeant.org> 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: khera@kciLink.com Rockville, MD +1-301-545-6996
GPG & MIME spoken here http://www.khera.org/~vivek/
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Honza Pazdziora <ad...@informatics.muni.cz>.
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, '<HELP>If 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 | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
------------------------------------------------------------------------
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Doug MacEachern <do...@covalent.net>.
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)
Posted by Matt Sergeant <ma...@sergeant.org>.
On Fri, 19 May 2000, Doug MacEachern wrote:
> > I would say that the bigger picture is definitely not generating HTML with
> > functions - use templates or stylesheets.
>
> you're probably right. but that's not what i was getting at.
> i was trying to make points about the bigger picture in general. trying
> to answer "why write something in c that's so simple to write in Perl?".
Damn - forgot smiley. Sorry :-)
--
<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)
Posted by Doug MacEachern <do...@covalent.net>.
> I would say that the bigger picture is definitely not generating HTML with
> functions - use templates or stylesheets.
you're probably right. but that's not what i was getting at.
i was trying to make points about the bigger picture in general. trying
to answer "why write something in c that's so simple to write in Perl?".
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Matt Sergeant <ma...@sergeant.org>.
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)
Posted by Doug MacEachern <do...@covalent.net>.
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)
Posted by Autarch <au...@urth.org>.
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)
Posted by Doug MacEachern <do...@covalent.net>.
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 [RV 52 bytes] 0x891b9b4
2: undef [GV 81 bytes]
3: undef [NULL 24 bytes] 0x891ba44
4: undef [NULL 24 bytes] 0x891ba5c
5: $unused [NULL 48 bytes] 0x891ba50
6: $string [PV 63 bytes] hi
now let's look at CGI::start_html:
============================================================
Totals: 15595 bytes | 330 OPs
============================================================
PADLIST summary:
8: $title [PV 78 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 [PV 56 bytes] <HTML><HEAD><TITLE>
46: undef [PV 81 bytes] <HTML><HEAD><TITLE>Untitled
Document</TITLE>
48: undef [PV 65 bytes] <LINK REV=MADE HREF="mailto:
59: undef [PV 49 bytes] <BASE HREF="
77: undef [PV 48 bytes] <NOSCRIPT>
94: undef [PV 49 bytes] </HEAD><BODY
96: undef [PV 50 bytes] </HEAD><BODY>
100: undef [PV 45 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">
<HTML><HEAD><TITLE>Untitled Document</TITLE>
</HEAD><BODY>
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)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by w trillich <wi...@pinncomp.net>.
"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. 500000 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 500000-element array in
> Perl takes up vastly more memory than building a 10000000-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: RFC: Apache::Request::Forms (or something similar)
Posted by Doug MacEachern <do...@covalent.net>.
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)
Posted by Gunther Birznieks <gu...@extropia.com>.
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 (gunther.birznieks@extropia.com)
Extropia - The Web Technology Company
http://www.extropia.com/
Re: RFC: Apache::Request::Forms (or something similar)
Posted by brian moseley <ix...@maz.org>.
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)
Posted by Doug MacEachern <do...@covalent.net>.
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 30000 iterations of array, concat, ref_array...
array: 8 wallclock secs ( 6.90 usr + 0.27 sys = 7.17 CPU) @4184.10/s (n=30000)
concat: 7 wallclock secs ( 5.98 usr + 0.16 sys = 6.14 CPU) @4885.99/s (n=30000)
ref_array: 5 wallclock secs ( 4.59 usr + 0.16 sys = 4.75 CPU) @6315.79/s (n=30000)
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)
Posted by brian moseley <ix...@maz.org>.
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)
Posted by "Jeffrey W. Baker" <jw...@acm.org>.
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. 500000 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 500000-element array in
Perl takes up vastly more memory than building a 10000000-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)
Posted by brian moseley <ix...@maz.org>.
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.
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Autarch <au...@urth.org>.
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)
Posted by Doug MacEachern <do...@covalent.net>.
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.
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Gunther Birznieks <gu...@extropia.com>.
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 pmh@edison.ioppublishing.com
>"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)
Posted by Gunther Birznieks <gu...@extropia.com>.
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)
Posted by Autarch <au...@urth.org>.
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
==================*/
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Drew Taylor <dt...@vialogix.com>.
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)
Posted by Peter Haworth <pm...@edison.ioppublishing.com>.
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 pmh@edison.ioppublishing.com
"Who needs horror movies when we have Microsoft"?
-- Christine Comaford, PC Week, 27/9/95
Re: RFC: Apache::Request::Forms (or something similar)
Posted by Autarch <au...@urth.org>.
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
==================*/