PHP and the web

[David A. Sinck]

\_ SMTP quoth David P. Schwartz on 4/10/2001 02:40 as having spake thusly:
\_
\_ [...]
\_ Honestly, there was so much stuff
\_ needed to tailor for different browsers it was nerve-wracking.  

Aren't the browser wars fun?  Welcome to the trenches.

\_ I played around with some Perl early last year and just about
\_ choked myself.  Perl is a nice language, but it has the annoying
\_ property that stdout is still the console (somewhere), rather than
\_ the HTTP session.  

Um, it must have been horrendously misconfigured for just you.  I have
had zero problem with getting output to hit the HTTP session when I
meant it to.

\_ Working with Perl is like learning to work with
\_ marionettes -- string puppets.  You're standing above them trying
\_ to make these things appear somewhat realistic while your view is
\_ perpendicular to that afforded your audience.  Not my idea of fun.

I have a feeling of an amusing exchange about looming.

\_ Then I picked up PHP last fall and wondered where it had been
\_ "hiding out".  Talk about a breath of fresh air!
\_ 
\_ The only tough part is the somewhat "religious debate" of whether
\_ to mix PHP code and HTML tags in the same file or keep them
\_ separate.  The best argument I've heard for separating them is to
\_ allow for template-based forms management.

Separating the execution from the cosmetics can help a lot,
particularly if you have a team where one is doing to glitz and the
other is doing the razz-matazz.

\_ 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.

\_ They both have valid arguments on both sides, but neither of the
\_ arguments are limited by the language the way Perl (and ASP, to a
\_ lesser extent) is.

I have to say I haven't seen a limitation in Perl throwing CGIs.  If
Perl is a limiting factor for you, let me name a few libraries that
could potentially simplify your next encounter:

CGI
LWP
HTML::Template
HTML::Parser
Mason
embperl
mod_perl

All available at a CPAN (http://www.cpan.org/ `perl -MCPAN -e shell`)
near you.   Well, more or less.  The last two may have their own sites
in paces. 

David
aged cgi joe