I'm actually working with a hybrid approach at the moment. I had a function which parsed the input to separate it, but I wasn't happy with the way it worked, and I might be moving over to using multipart/form- data forms, which are _way_ more of a pain to parse. So I looked at CGI.pm. Pros: I don't have to parse the data -- I can get it from the object. I can still get most of the ENV variables (I think) by just accessing them -- at least, I haven't run into a problem with that so far, although I only really need one or two. It makes creating certain structures much easier -- ie, dynamicly created <select>s, and checkbox groups (which are the two big input types I'm working with right now). Cons: you have to be careful to force it not to passthrough all the data -- otherwise things can get confusing -- in particular, investigate the "-override=>1" option... You can't easily get the query string parameters in the same space as the POST parameters (although some might consider this a plus). One important thing to note is that the output from all of the form object and html tag creation routines is just text. Which means that there is no problem with you putting your own HTML stuff in there. I find that I use the CGI routines to create the form parts, but I write most of the structural HTML by hand. I actually think that you almost have to do this, because otherwise creating tables is an exercise in _really_ understanding how "map" works.... I will say that it has allowed me to speed up the generation of my form HTML greatly. I would just ignore most of the HTML generating routines (except for header, and perhaps start_html() and end_html()). Also, of course, I really like that fact that moving to multipart/form- data forms (the docs claim) would be seamless.... I suggest trying it -- I prefer to use the OO methods, as they keep things cleaner -- and seeing if you like it. Try a simple CGI in it. After all -- you may have a completely different opinion.... HTH, Ricky On Wed, Dec 20, 2000, at 1:52 PM, robinmcf@altern.org wrote: >Richard Smith <unfeasibly_tall@yahoo.com> wrote: >>I wondered if anyone could offer me their pros and >>cons of using the CGI.pm over doing it the long way. ...... > >Cons (for me): >I usually end up writing any forms the CGI wil generate with a HTML editor >because I don't enjoy farting around with cgi objects - if I want to make >changes to the layout of a page it's a lot quicker to throw together and >check if I do it in a HTML editor, and paste this into the script, or use >it as a template which the CGI parses. > >If I want to get at a ALL of the ENV variables I have to hand code the old >fashioned way (ok I'm a control freak) > > >Pros: >it's transparent, easy to use and it works. ----- Pukku ==== Want to unsubscribe from this list? ==== Send mail with body "unsubscribe" to macperl-webcgi-request@macperl.org