Jacob,
I am been saving this article for some time, about
PHP Vs CGI Comparsions, I know it is somewhat off the
current CF tropic, but I throught that you all might
find it interesting for futhur references.
Joe Cervenka
PHP Vs CGI
PHP seems very much in vogue now-with an increasingly
greater number of web hosts providing support for it.
For those who have only vaguely heard of it and are
not too sure what it is, this article discusses PHP
and informally compares it with writing CGI scripts in
Perl.
PHP is a free server side scripting language. It can
be built into web servers like Apache and you can use
it to generate your pages dynamically. You would
probably use it in situations you would have otherwise
used a CGI script for.For example thefreecountry.com's
Feedback form (among other things) uses a PHP script
to generate the form and send the message to me.
1. The Language
If you are coming from a C, C++, Perl, Java or
JavaScript background, learning PHP would probably be
a piece of cake. In fact, you probably can get started
writing your scripts almost immediately (I did).
It uses typeless variables the way Perl does, prefixed
with a "$" sign and holding any data type you wish.
For example, $whatever can be a variable that you can
use to contain strings, numbers, whatever. If
$whatever contained a number, you can increment its
value using
$whatever++ ;
or
$whatever += 1 ;
or
$whatever = $whatever + 1 ;
Remind you of Perl, C, C++, Java, JavaScript? See what
I mean?
2. Built-in Facilities
Unlike Perl, which is a general purpose scripting
language that you can use for a wide variety of
purposes (and not just generating web pages), PHP was
designed from the ground up to be used for scripting
web pages. As a result, it has lots of facilities
built into that you may have to write yourself or use
some pre-written module if you were using Perl.
For example, do you want to send email to yourself
from a form on the web page? In Perl, you probably
would have to code something like the following:
open ( MAIL,"|/usr/sbin/sendmail -t");
print MAIL "To: [EMAIL PROTECTED]" ;
print MAIL "From: [EMAIL PROTECTED]" ;
print MAIL "Subject: Comments from Web Form\n\n" ;
print MAIL $mainmessage ;
close ( MAIL ) ;
In PHP, the same thing would be coded as follows:
mail ( "[EMAIL PROTECTED]", "Comments from Web
Form",
$mainmessage, "From: [EMAIL PROTECTED]" );
Nifty, huh? The same goes for other facilities like
sending or retrieving a document via HTTP or FTP, etc.
Since PHP was specially designed for a website, the
facilities that web designers typically want in a
scripting language are built into it.
Another convenience is its handling of form input.
Take for example a form with a field like:
<input type=text name="dateofbirth">
You can immediately access that field with the
$dateofbirth variable. No need to parse form inputs
and the like. All fields in the form are automatically
converted to variables that you can access.
Accessing databases is just as easy. There are
built-in facilities in PHP to access MySQL, MSQL,
Dbase, Oracle, InterBase, and so on (the list is very
long). Need to MIME encode your message? There's a
function to do it for you too.
There're lots more. I obviously can't run through the
entire list - it would take a whole book to be
exhaustive. This is just to whet your appetite.
3. Generating web pages
By default anything you type in your PHP document is
given verbatim to the web browser. So a simple PHP
script might look like the following:
<html>
<head><title>My First PHP Script</title></head>
<body>
<h1>My First PHP Script</h1>
<p>
Welcome, Internet user from IP address
<?echo $REMOTE_ADDR?>. Hope you like my first
PHP page.
</body>
</html>
Notice that it looks exactly like a web page, except
for the <? ... ?> bit, which encloses the PHP script.
In this case, all we want is for the script to output
the visitor's IP address to the page, hence we use the
"echo" function. The web server's environment variable
REMOTE_ADDR is automatically made available to the PHP
script via a variable of the same name (as are all
other environment variables and form inputs).
There are many ways to embed your PHP script into your
page, or to design your page itself. But you got the
general idea. As I said, PHP was designed for web
pages, so the idea of output to the server is built
into its design. It makes writing such scripts a very
pleasant task.
4. Debugging With PHP Vs Perl CGI
Interestingly, if you're debugging your scripts
online, PHP really shines.
Normally, when a Perl CGI script goes awry, you'll get
a cryptic error message in your browser: something to
the effect of "500 Internal Server Error".
With PHP scripts, you get error messages pinpointing
the offending lines in your code to help you locate
the error. However, the message is sometimes a cryptic
"parse error" or the like, so you still have to crack
your head to figure out the problem. But at least you
know where it occurred. Contrast that with Perl CGI
scripts, where an "Internal Server Error" could have
arisen from any number of causes, from a syntax error
to a simple case of forgetting to make the file
executable or uploading it in text mode.
Debugging offline, however, is another story. Some
people have found that the Perl interpreter gives more
helpful messages than the PHP interpreter, which tends
to label many things as "parse error". This may
change, though, as newer versions of the PHP
interpreter is released.
4. What's the Catch?
While I obviously enjoy using PHP as my web scripting
language, I do not claim that it is the perfect
solution for all your website needs.
You might want to consider the following prior to
committing yourself ot it. The list, incidentally, is
not exhaustive.
a. Not all web hosts provide PHP facilities. While it
is true that many also do not provide CGI access, the
number providing PHP is even less!
In fact, where free web space providers are concerned,
the number providing PHP can probably be counted with
one hand. Indeed, even if you manage to find free web
hosting with PHP access, you have to ask yourself
whether you really want to depend on it for your site.
There might be a day when you need to move your site,
and you may be hard-pressed to find another free web
host that supports PHP.
However, if you host with commercial web hosting
companies, you probably will have less problems. It
seems to me like the large majority of vendors support
PHP, and even those who currently don't provide it
plan to support it in the near future.
b. Like all web scripting languages (Perl included),
debugging the script can be a pain in the neck unless
you download and install your own copy of PHP.
Otherwise you might spend many hours online trying to
test and debug your script (unless of course it's a
trivial script).
Incidentally, you can also operate your own Apache web
server at home, so as to mimic the entire environment
of your actual site (or as close to it as necessary).
Of course if you have a Linux box around, you're
probably all set. Just dig up your installation CDROMs
and install the server and PHP module from there if
you've not already done so. (Most modern Linux
distributions come bundled with the Apache server and
PHP Apache module.)
c. It is not a general purpose language. While it has
many facilities specifically catered towards web
programming, it is not Perl (or C or C++ or Java). I
personally however find PHP more than adequate for my
web programming needs.
5. Where to Get It?
The entire PHP documentation set comprising the
reference manual for the various PHP language features
and functions can be downloaded from the PHP web site
at:
http://www.php.net/
The sources and binaries for PHP can also be found on
that site should you wish to run a copy on your own
machine for testing purposes.
--- Jacob Cameron <[EMAIL PROTECTED]> wrote:
> I agree with Ben Forta, there is no apples to apples
> comparison.
>
> If you are integrating with Office (excel, word, or
> outlook automation) or
> COM objects, I would use .NET. .NET has a lot of
> advantages on the windows
> platform. However, saying that CF is better because
> you can run it on
> multiple platforms does not hold water because PHP
> runs on more platforms
> than either one. Also, I have converted a few sites
> from Linux to windows
> and windows to Linux (and UNIX), it has never been
> smooth.
>
> I use CF if I can get away with it.
>
> .NET is not just a development platform, but it is a
> whole new way of doing
> web development. Therefore learning for existing
> programmers is tough, you
> have to forget your normal CGI patterns of
> programming that you have become
> used to over the last 12 years. Server site form
> elements confused me at
> first, it seemed like a stupid way to do it, but I
> got used to it. Just
> like I got used to tag based coding (That seemed
> stupid to me at first also)
> when moving from EXE's and ASP to CF 7 years ago.
>
> It's just another web development language meant to
> confuse us and waste our
> time arguing and training. A lot of us forget:
>
> The right tool for the right job.
>
> Jacob
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Matthew Woodward
> Sent: Thursday, June 09, 2005 8:45 AM
> To: [email protected]
> Subject: Re: CF VS .Net?
>
> Probably the best resource for this discussion is
> here:
> http://forta.com/blog/index.cfm?mode=e&entry=1266
>
> Sean Corfield from Macromedia also recently had a
> blog post in which he
> mentioned that they built the same app in both C#
> and CF and CF took
> somewhere on the order of 1/4 the development
> time--I'll try and dig that
> up.
>
> There was also a very long thread several months ago
> on the Macromedia
> forums about this (mostly perpetrated by yours
> truly) but I can't dig it up
> in their search. Some of the high points as I
> remember them were these:
> * more flexibility for deployment with CF (server
> OS, J2EE, .NET with
> BlueDragon, etc.)
> * faster development times with CF typically
> * more out-of-the-box features with CF (graphing,
> reporting, Verity),
> although .NET does have some nice front-end controls
>
> The ONLY con really is that CF 'isn't free,' but of
> course with .NET you
> have to pay for Windows and the application has to
> live on Windows the rest
> of its life. Also even on moderate-sized projects,
> the CF license cost pays
> for itself with all the extras you don't have to buy
> and the savings in
> development time.
>
> That should be enough to get the ball rolling. ;-)
>
> Matt
>
> On Jun 9, 2005, at 6:56 AM, David Whatley wrote:
>
> > Just for discussion, what are the pro's and cons
> on CF versus .Net?
> >
> > David Whatley
> > COO
> > AutoRealty Products
> > 817-284-9875 X 105
> >
> >
> >
> >
>
----------------------------------------------------------
> > To post, send email to [email protected] To
> unsubscribe:
> >
> http://www.dfwcfug.org/form_MemberUnsubscribe.cfm
> > To subscribe:
> >
> http://www.dfwcfug.org/form_MemberRegistration.cfm
> >
> >
> >
>
> --
> Matthew Woodward
> [EMAIL PROTECTED]
>
>
>
----------------------------------------------------------
> To post, send email to [email protected]
> To unsubscribe:
> http://www.dfwcfug.org/form_MemberUnsubscribe.cfm
> To subscribe:
>
> http://www.dfwcfug.org/form_MemberRegistration.cfm
>
>
>
>
>
----------------------------------------------------------
> To post, send email to [email protected]
> To unsubscribe:
> http://www.dfwcfug.org/form_MemberUnsubscribe.cfm
> To subscribe:
>
> http://www.dfwcfug.org/form_MemberRegistration.cfm
>
>
>
__________________________________
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html
----------------------------------------------------------
To post, send email to [email protected]
To unsubscribe:
http://www.dfwcfug.org/form_MemberUnsubscribe.cfm
To subscribe:
http://www.dfwcfug.org/form_MemberRegistration.cfm
