CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
Search Posts SEARCH
Who's Online WHO'S
Log in LOG

Home: General Discussions: General Questions:
Parsing forms...



Apr 2, 2001, 7:46 PM

Post #1 of 7 (5959 views)
Parsing forms... Can't Post

Well I have a friend and evertime we bring up perl programing we debate upon what method is better of parsing forms.

I have built a forum software... it's in my sig but I'm moving servers. You can see it at his website ( but he suggests I use a read parse subroutine in my scripts to parse all the forum data:

sub ReadParse { 
local(*in) = @_ if @_;
local($i, $key, $val);

if ( $ENV{'REQUEST_METHOD'} eq "GET" ) {
} elsif ($ENV{'REQUEST_METHOD'} eq "POST") {
} else {
$in = (grep( !/^-/,@ARGV))[0];
$in =~ s/\\&/&/g;

@in = split(/&/,$in);

foreach $i (0 .. $#in) {
$in[$i] =~ s/\+/ /g;

($key, $val) = split(/=/,$in[$i],2);

$key =~ s/%(..)/pack("c",hex($1))/ge;
$val =~ s/%(..)/pack("c",hex($1))/ge;

$in{$key} .= "\0" if (defined($in{$key}));
$in{$key} .= $val;
return length($in);

but I keep insisting to him that using is much more realiable way:

use CGI; 
my $obj = new CGI;
my %in = map {$_ => $obj->param($_)} $obj->param();

anyway, I want some facts from people that know the ends and outs of both methods and which they would prefer.

Fueled By ZCom


Apr 2, 2001, 8:01 PM

Post #2 of 7 (5958 views)
Re: Parsing forms... [In reply to] Can't Post

Now lets discuss why I advocate using a simple function to parse his forms rather than

First of all, the ONLY function he uses out of is the form parser. It's absolutely pointless to include all of in each of your scripts if you're only using that one function. Even though it's a module, on a heavily visited message board, that use of in every CGI file will certainly increase server load significantly. Which would be FINE, if he actually used a good portion of the functions available in

Now, I don't necessarily think he should use that exact function he posted above. If he likes the way does it, fine, take their code (the portions you actually use) and put it in your own file, then require it into your scripts. This would significantly decrease the server load, and the scripts would execute more quickly. Plus, you would get the exact same behavior.

Why force the server to process all the instructions every time? Why force users to install modules they may not want? Why insist on using modules just for the sake of using modules?


Apr 6, 2001, 10:46 PM

Post #3 of 7 (5951 views)
Re: Parsing forms... [In reply to] Can't Post

I have been told that programmers go through several stages in their attitude about

1. Don't know enough to use

They find a function similar to the one given here in a book somewhere and they use it, change it, (often mess it up at least once), and then copy it into all of their scripts.

2. The phase

Now the programmer knows of and uses it.

3. Knows enough to not use

Eventually they realize that they really only need one or two functions from the monster that is So they write a module or put the function into a configuration module or required file so all of their scripts can use the new light version.

If you do a search through the old threads here for 'CGI' you will find many variations of this function. And almost as often you will find a warning that you really don't want to write your own.

CPAN does have some lighter alternatives if you don't want to write your own but do want something smaller...

use CGI;
use CGI::Minimal;
use CGI::Lite;
use CGI::Thin ; #the smallest of the modules
require ''; #the old perl4 solution

I wrote CGI::Thin to have the one function that I needed and drop all the other filler of the larger modules. Eventually I will put out the new version that will also read and write cookies, but that is as much as I plan on ever adding as it would no longer be Thin.

Sun Sep 9, 2001 - 1:46:40 GMT, a very special second in the epoch. How will you celebrate?


Apr 7, 2001, 3:23 AM

Post #4 of 7 (5950 views)
Re: Parsing forms... [In reply to] Can't Post

 I'm to the point where I only use it for upload scripts,

The rest of the time I use

sub parse_form {
my (@pairs, %in);
my ($buffer, $pair, $name, $value);

if ($ENV{'REQUEST_METHOD'} eq 'GET') {
@pairs = split(/&/, $ENV{'QUERY_STRING'});
elsif ($ENV{'REQUEST_METHOD'} eq 'POST') {
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
else {
print "You cant run this script from telnet/shell.\n";

PAIR: foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);

$name =~ tr/+/ /;
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

($value eq "---") and next PAIR;
exists $in{$name} ? ($in{$name} .= "~~$value") : ($in{$name} = $value);
return %in;
%in =&parse_form;

I'm just more comfortable with the values being stored in a hash.

I think it really depends on the size of the script and the amount of fields sent to your script. If I'm only passing less than 10 then I might use, but anymore then I get sick of


I found that you can have pack the values and keys into a hash for you, but like Brian said why pull in a huge file just for the form parse.

Also with I can't get away with things like

?name=This is some text & more text

Where I can modify the code above to let me.

Silly but I needed to do it yesterday.



Apr 7, 2001, 12:35 PM

Post #5 of 7 (5947 views)
Re: Parsing forms... [In reply to] Can't Post

sleuth, you don't need to use the $in = param('whatever') -- you can use the syntax that zanardi offered above:

my %in = map {$_ => param($_)} param();

Now all of the input is in %in. I'm not sure what you meant about " not letting you get away with ?name=This is some text & more text"

As for the 3 stages noted about attitude towards well, I would tend to disagree with that. Step 3 said "Knows enough to not use". And in response, I offer that: is used in nearly all of http://column about converting HTML to

With the exception of browser output that's just a couple of lines (like a counter), is used exclusively in the newly published book, Writing CGI Applications with Perl, by Kevin Meltzer and Brent Michalski.

I would say that the above people know enough about Perl, and advocate's use "anyway".

I couldn't sum it up better than Ovid's use CGI or die; node on PerlMonks. Just read it Smile

It seems like a good percentage of the questions posted on this forum can be answered simply by pointing a user to the appropriate function. To wit:

- How do I set/retrieve cookies? (cookie)
- How do I upload files/why isn't my upload code working? (start_multipart_form)
- Why isn't my page showing in Netscape? (table)
- How do I redirect to another page? (redirect)
- Why am I getting premature end of script headers? (header)
- How do I have a multi-page form? (hidden)

I love the shortcuts, particularly the html shortcuts. I don't know about anyone else, but I recall the days when the program is "done", it works beautifully, then to realize that the output looks funky in one browser or the other. helps you focus on Perl programming, not HTML coding.

But, if someone is intending to use just less than a handful of functions, or for a simple program whose sole purpose is to output one or two lines to the browser, I agree that is overkill. On the flip side, if you became a bit more familiar with, you may realize that a lot of things that you're doing manually can be handled by "CGI programming" inherently means that HTML code will be included. Passing off the HTML to sounds logical because we're programming Perl, and we shouldn't have to waste brain energy on trying to remember if the table tag, list, div, etc. was closed.

Because I use so frequently, I've tossed together a quick reference of its functions. You can see/use it at <A target="_blank" HREF= -- kid tested, mother approved.


Apr 18, 2001, 7:46 PM

Post #6 of 7 (5924 views)
Re: Parsing forms... [In reply to] Can't Post

Ok, well It seems you all agree that is a big file. I agree as well 6000 lines is a lot for a file. I know there are many alternatives to what I am doing. But for right now I just want to make sure that you agree that I should use over a read-parse routine like what I posted above. My friend Mark Badolato told me that I should always use over a simple read-parse routine because is supported and it's more stable

Fueled By ZCom


Apr 18, 2001, 9:14 PM

Post #7 of 7 (5923 views)
Re: Parsing forms... [In reply to] Can't Post

I definitely recommend the use of Not only for parsing, but for everything it can be used for. After all, if you plan on using, why not take full advantage of it by learning its methods.

If you're really interested in, I'd recommend checking out Official Guide to Programming With Cgi.Pm by Lincoln Stein (the author of the module).

As one reviewer said about the book on Amazon's site "If you write CGI scripts in perl and are not taking advantage of, then you're doing things the hard way."


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives