> \_ 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
(text/plain)