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:

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?

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?

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

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.

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

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.