> \_ Another aspect is whether to have separate scripts for handling
> \_ GETs and POSTs for the same screen.
>
> What?  Please show me the debate thread on this.  Someone thinks its
> better to have some scripts run when called as GETs and others when
> POSTed?  I'd love to know how they convince a webserver to fork the
> request based on method.  I've branched logic in the code based on
> request_method, but never have separated two instances of requests to
> separate scripts.
>

Maybe I misstated something.  Perhaps there isn't much of a "debate".  I've
got a few Perl books and they all routinely separate GET and POST processing
for the same form into different CGI files.  I don't know anything about
server forking; the script writers just specify different files in the <FORM
...> tags.

Even the PHP books written by ex-Perl junkies show their scripts this way.

I prefer to handle the GET and POST processing for one form in the same script
file, not in two different files.  It makes dealing with field validation much
easier: the POST-handling code can simply cause the form to be re-displayed
with an error message and ready to re-POST, rather than relying on the user to
click the Back button.  The Perl code I've seen that handles this in a single
CGI file seems way convoluted to me.

If you've got a lot of Perl experience, then maybe all this is second nature
to you.  I'm speaking from someone who spent a month or so playing around at
adapting about a half-dozen scripts to make some relatively simple things
happen.  Debugging was a bitch -- I don't like having to search through my web
logs to find error messages that never showed up in the HTTP stream.  Every
book I've read says Perl was designed originally as a report printing
language, which it appears it would be quite good at.  Its use as a CGI
scripting language is a strange adaptation.  PHP is FAR more natural to use in
that capacity.

Anyway, the other thing I REALLY love about PHP that I forgot to mention is
the way it integrates all the HTTP vars directly into the programmer's
namespace.

Look, I'm no language bigot.  I just prefer languages that fit the
application, and PHP seems to be a way better fit for web page scripting than
Perl.  It's easier to write (I'm more familiar with C than with Awk), it's
easier to debug (having a single namespace and being directly in the HTTP
stream by default), and it's easier for me to grok conceptually for design
purposes.

If time == money, then Perl is a very costly language for me to use.  It could
be the coolest thing on the planet, but I find PHP far, far easier to work
with given my particular background.  YMMV :-)

-David Schwartz