Hi Randal, I must take issue with you here. Whatever the convenience of such utilities in a production environment, there is a definite advantage to the learning process in hand-coding. I learned something just from reading the example--that there was a specific MIME for httP posts. Whatever convenience more abstracted libraries might offer, I am sure that that bit of information is more likely to help me out in the unique pinch.
As for form parameters, I disagree even ore strongly, One of the greatest strenths of the standard html format is its text readability and accessibility [when written well, at least. What better exercise to link the concepts of server-side management and client manifestation than to ouitpit the html directly to the client. Realistically, you provided most of what is needed in examples in your book. A quick look at the query-parsing routine in a working CGI script shows the essentials needed to extract uploaded information, at least the textual content, from the query string. Nor does it hurt a student to knock his or her head against the rules for various html objects. A certain amount of initial frustration can help to engrain the lessons about what works where, and why. Sometimes there is also an advantage in efficiency. The first tow serious CGI scripts I have rolled out used my own code for some functions that I know are built in--somewhere. I just don't have the time to hunt for them. So now I have a couple functions, ParseQueryLine (hash & %contents) # I sorta miss my function prototypes OpenHTML (string Title, string[] @MetaTags) that I know exactly what I can do with. If I get tired of: "<select name=\"" . $When . "Date\" size=1 " . "value=\"$Today[1] $Today[2] $Today[4]\"> $Today[1] $Today[2] $Today[4] <br>" ); I can probably make some AddSelectObject function to abstract that work, also. You notice though, that the real work was in getting the information into the parameters. The only work added by hand coding the html are the "name=" and "value=" parts of the tag. [I might have saved some overhead by turning the three array elements into a single string, but that is a design question beyond the scope of whether direct coding aids the learning process.] The point is that I can see very direct cause and effect relationships between what I code in Perl, and what shows up in the source and on the browser. Happy Coding, Joseph "Randal L. Schwartz" wrote: > > It's misleading to handcode application/x-www-form-urlencoded values > when more proper higher-level functions are available, such > as HTTP::Request::Common. > > I thought the URL was pointing at "lwpcook". Apparently it wasn't. > > So now I'll say "perldoc lwpcook" is *the* place to start. And it > *does* prefer HTTP::Request::Common to hand-rolling any code that > refers to form parameters. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
