Perl Guru Forums: General Discussions: General Questions: Parsing forms...

CGI/Perl Guide | Learning Center | Forums | Advertise | Login

Site Search: in


	MAIN INDEX	SEARCH POSTS	WHO'S ONLINE	LOG IN

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

zanardi
journeyman

Apr 2, 2001, 7:46 PM

Post #1 of 7 (4199 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 (www.massassi.net/serious/) but he suggests I use a read parse subroutine in my scripts to parse all the forum data:

Code

sub ReadParse { 
	local(*in) = @_ if @_;  
	local($i, $key, $val); 
 
	if ( $ENV{'REQUEST_METHOD'} eq "GET" ) { 
		$in = $ENV{'QUERY_STRING'};  
	} elsif ($ENV{'REQUEST_METHOD'} eq "POST") {  
		read(STDIN,$in,$ENV{'CONTENT_LENGTH'});  
	} 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 CGI.pm is much more realiable way:

Code

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

BrianL
Deleted

Apr 2, 2001, 8:01 PM

Post #2 of 7 (4198 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 CGI.pm.

First of all, the ONLY function he uses out of CGI.pm is the form parser. It's absolutely pointless to include all of CGI.pm 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 CGI.pm 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 CGI.pm.

Now, I don't necessarily think he should use that exact function he posted above. If he likes the way CGI.pm 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?

rGeoffrey
User

Apr 6, 2001, 10:46 PM

Post #3 of 7 (4191 views)

Re: Parsing forms... [In reply to]	Can't Post

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

1. Don't know enough to use CGI.pm

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 CGI.pm phase

Now the programmer knows of CGI.pm and uses it.

3. Knows enough to not use CGI.pm

Eventually they realize that they really only need one or two functions from the monster that is CGI.pm. 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 'cgilib.pl'; #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?

sleuth
Enthusiast

Apr 7, 2001, 3:23 AM

Post #4 of 7 (4190 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";
exit;
}

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 CGI.pm, but anymore then I get sick of

$field=param('field');

I found that you can have CGI.pm 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 CGI.pm 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.

Tony

Jasmine
Administrator

Apr 7, 2001, 12:35 PM

Post #5 of 7 (4187 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:

Code

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 CGI.pm... well, I would tend to disagree with that. Step 3 said "Knows enough to not use CGI.pm". And in response, I offer that:

CGI.pm is used in nearly all of http://column about converting HTML to CGI.pm

With the exception of browser output that's just a couple of lines (like a counter), CGI.pm 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 CGI.pm'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 CGI.pm 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. CGI.pm 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 CGI.pm is overkill. On the flip side, if you became a bit more familiar with CGI.pm, you may realize that a lot of things that you're doing manually can be handled by CGI.pm. "CGI programming" inherently means that HTML code will be included. Passing off the HTML to CGI.pm 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 CGI.pm so frequently, I've tossed together a quick reference of its functions. You can see/use it at <A target="_blank" HREF=http://nwark.pm.org/pm/reference/CGI-pm/allbyname.shtml.

CGI.pm -- kid tested, mother approved.

zanardi
journeyman

Apr 18, 2001, 7:46 PM

Post #6 of 7 (4164 views)

Re: Parsing forms... [In reply to]	Can't Post

Ok, well It seems you all agree that CGI.pm 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 CGI.pm over a read-parse routine like what I posted above. My friend Mark Badolato told me that I should always use CGI.pm over a simple read-parse routine because cgi.pm is supported and it's more stable

----------------------
Fueled By ZCom

Jasmine
Administrator

Apr 18, 2001, 9:14 PM

Post #7 of 7 (4163 views)

Re: Parsing forms... [In reply to]	Can't Post

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

If you're really interested in CGI.pm, 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 cgi.pm, then you're doing things the hard way."

Search for (options)

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