Slashdot Mirror
Writing CGI Applications with Perl
The problem, of course, with most Perl CGI books is that they are written by people who just don't know very much Perl. That's certainly not the case here. Both Kevin and Brent are well-respected members of the Perl community and they know what they are talking about when it comes to writing CGI programs in Perl.
Another common mistake in Perl CGI books is that the authors try to take people who know a bit of HTML and teach them programming, Perl and CGI all at the same time. The authors of this book realise that this approach is likely to lead to, at best, patchy understanding of any of these concepts so they aim there book at people who are already programmers and who have some knowledge of Perl. This means that they can concentrate of teaching the parts of Perl that are useful when writing CGI programs.
One corner that is often cut when discussing CGI programming is security. This is a very dangerous approach to take as a badly written CGI program can leave your web server open to attack from anyone on the Internet. That's not a mistake that is made here as the authors introduce security in chapter 2. Add to that the fact that the code examples all use -w, use strict and CGI.pm and the book is already head and shoulders above most of its competition.
Early chapters look at common CGI requirements such as file uploads and cookies. Each chapter is full of well written (and well-explained) sample code. The example of an access counter in chapter 6 even locks the file containing the current count - this is possibly a first in a Perl CGI book!
By the middle of the book we have already moved beyond simple CGI programming and are looking at mod_perl. This chapter covers both the "faux-CGI" Apache::Registry module and also writing complete mod_perl handlers.
In the second half of the book we start to look at some bigger examples. The authors present a web-based email system and even a shopping cart. In order to fit these examples into their respective chapters a couple of corners have been cut, but there's enough information there to enable anyone to write the complete systems.
Chapter 13 introduces the HTML::Mason module as a way to separate content from presentation. It's obvious that the author's are big fans of this module and this leads to my only real criticism of the book. At no point do they mention the fact that the same benefits can be gained from using any of half a dozen templating systems found on the CPAN. I would have been a lot happier if they had mentioned things like Text::Template, HTML::Template and the Template Toolkit before picking HTML::Mason as the system for their example.
There are then two more long chapters with examples of a document-management system and image-manipulation software. Once more, the code in these examples would serve as a great starting point for anyone wanting to implement something along these lines. The last chapter looks at XML and, in particular, the use of RSS files to provide data feeds to other web sites.
All in all this is a very useful book for someone wanting to write web-based applications using Perl. It's packed full of good advice and code that follows all of the best practices for writing CGI programs in Perl. This book won't teach you Perl, but if you've read Learning Perl or Elements of Programming with Perl then you'll find this book easy enough to follow.
You can purchase Writing CGI Applications with Perl from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then hit the submission page.
This is a little late in the game for a book that discusses ways to fork off a separate process for each hit on your dynamic pages. I'm sure the authors are studs and all, but if you're programming web applications in Perl, how about using mod_perl, and if you're going to do that, why not bite the bullet and buy Lincoln Stein and Doug Eachern's book from O'Reilly? It is a classic.
Speaking of classics, the old "Writing Web Clients with Perl" is being superseded this month by Sean Burke's "Perl and LWP". Now speaking of Perl studs, they don't get much studlier than Sean, and LWP is (IMHO) the Killer App for Perl programmers. Another fine O'Reilly title (too bad "fine O'Reilly title" is not redundant anymore).
Also from O'Reilly (yawn) is Rasmus Lerdorf's "Programming PHP". I was *very* pleasantly surprised by his book, it is MUCH better than it has any right to be, discussing everything from PEAR DB abstraction classes to speeding up your site with a Squid reverse cache and profiling.
Anyways, that's just my shelf's worth. I use Perl and PHP every day (or at least every day I wear my programmer hat) to get things done fast. I know other people prefer Python and Ruby, hey, more power to them. But I figured I would point out some Fine O'Reilly Titles (note, once again, that phrase is now said more like "Honest Senator" rather than "Stupid Microsoft Security Hole") which have made me some money lately.
YMMV...
Remember that what's inside of you doesn't matter because nobody can see it.
HTML::Mason is one of the most sophisticated Perl tools for templating web sites, and indeed it does a whole lot more than mere templating.
It'd be my first choice for including in a general book as although it can get more complex (and powerful) when necessary it is actually very easy to use for simple sites.
However yes to be fair you'd not want to ignore the very good work done by other module authors.
Sure, when perl was booming, CGI was all about the web, but now-a-days you find more PHP in use than perl for quick projects (or ASP for IIS users), and ColdFusion or J2EE for large web apps (I prefer J2EE with struts and taglibs, as they are cleaner).
Hate to sound like a "*BSD is Dead" troll, but CGI is a dying breed (NOT PERL, just CGI). I'd suggest skipping this book in lew of a more popular web-app language.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
You may be able to learn some neat things in Perl in 24 hours, but will you remember them without the book in 24 more hours?
Rule #1 -- Politics always trumps technology.
Yet, I've found myself writing more and more smaller apps using PHP instead of perl. It's by the Apache group and essentially merges into the www server, making it very quick. You can still use mod_perl for perl apps.
Along with your preferred SQL database, progranmming in PHP is a breeze. Basically, write html pages and add the commands you need embedded inside. The best PHP book I have on that topic is PHP and MySQL Web Development (ISBN: 0672317842) second to none.
The key is that you can easily run CGI scripts - quite possibly unmodified - with mod_perl thanks to the wonders of the Apache::Registry module that ships with mod_perl. It's all covered in the guide.
-- Sorry, I can't think of anything funny to say here.
Your ignorance is exceeded only by your stupidity. CGI is, and I quote:
"A set of rules that describe how a Web Server communicates with another piece of software on the same machine, and how the other piece of software (the 'CGI program') talks to the web server."
This also makes PHP use CGI, so your comment is somewhat akin to saying "Windows is dead! Use Windows 2000!" or something equally thoughtless and banal.
As far as concerns intuitive, what do you mean? It's easier to learn? Or do you mean you can guess at writing it? Time to find a dictionary, young Jedi.
But, assuming you hadn't been talking utter nonsence, a quick look at jobserve, one of the biggest UK jobs sites, shows 812 ASP-related jobs, 351 Perl-related jobs, and 70 PHP-related jobs.
So, what *exactly* are you basing your ignorant comments on?
Score:-1, Funny
- It looks like a nice thick book, but it's very padded. The font is huge (12 to 14 points), there's a lot of padding
(most code samples listed twice, 40 pages of appendix material that could have
been 8 URLs), the margins are huge, and there's an awful lot of repetition (the
10 lines justifying -wT are repeated nearly every time it's used in a program). I bet that the Mouse book squeezes twice as much
content into 450 pages as this one does in 525.
- Some chapters belong better in a Perl book ("Tied Variables").
- Some inclusions/exclusions and focus choices are very odd. There's a very
detailed chapter for Mason, but no mention of templates (literally - not even in
the index).
- Their style is very choppy. They'll present a couple lines of code, then a
paragraph talking about it, repeat. It's very difficult to get a cohesive view
of the program this way - it's spoon-fed to you rather than presented whole. (Undoubtedly this is why they repeat all the code at the end of each chapter, but I prefer longer chunks of unbroken code).
In short, the book is much more vocational than educational. I think this was a conscious decision of theirs, and as such I can hardly fault it - they know their target audience better than I do. However, I've not opened this book once since I read it (cover-to-cover), while I still refer to the Mouse weekly.Need to hack up some code fast? This book will help. If you really want to learn CGI, to know why and how it works, to have a broader grounding in the technologies used with it, and to build a firm foundation for future self-teaching, then IMHO nothing beats the Mouse book.
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
nms is such a place. It has replacements for all of Matt's scripts - and Matt himself has suggested using them as replacements for his buggy versions
I'm sure the author of this review would agree with me that this is a good place to go to get scripts ;-)
-- Sorry, I can't think of anything funny to say here.
> ... the only exception that I can think of would be if you need to make a web application on a server that you don't admin ...
...).
;-).
You hit the nail on the head.
I run web sites on four machines. The one sitting in my home office is the only one where I'm the admin, and the ISP blocks port 80 on that one (not that this is a real problem, but
After experiments with PHP and Python, I've pretty much settled on perl for almost everything, with a few C programs as helpers. My perl CGI scripts run on all the machines without any changes, as do my C programs. With PHP and Python, I've found that every new machine requires a debug session to get anything to work, and I have to maintain huge sets of diffs for the different machines.
But with perl, I can drop a new script in all my directories, and they just work. I have exactly one "per-machine" file CGI file, which lists the directories in which things are installed. Even that isn't necessary, but it's faster than the code to discover where things are.
On one of my web sites, they still have perl 4, and my CGI scripts work fine. I can't install a current perl release, because my disk space there isn't enough to hold the unpacked perl source.
Also, all the timing tests I've been able to run have given perl a substantial edge over everything else except C. But this is a small sample set, due to the difficulties in matching perl's capabilities in PHP (and the difficulties getting a recent Python version installed
It would be nice to be able to depend on mod_perl, but the admins on several of these machines don't see the need for it. Even at several requests per second, my perl CGI scripts are an unmeasurable load on the machine. So why should the admins waste their time installing mod_perl for me, when it would only save a few seconds of cpu time per day?
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
"It's time to get rid of java because of its ugly syntax".
"It's time to get rid of japanese because of its ugly syntax".
If you don't know the language, you shouldn't be maintaining it.
Perl is quite elegant, and the $ # % all make sense. If you know Perl.
A classic, and no longer the only book in the field. mod_perl Developer's Cookbook is a tremendous tome, and I use it more than the the LDS/DOUGM book. It's well worth looking at.
It's not better than the eagle book, but if I could only buy one, that would be it.
Both books show how to run CGI programs under a mod_perl enabled web server, using Apache::Registry. So the myth of the server forking a new process for each request is not true. CGI and Perl in this day and age can actually run rings around an ASP solution without the performance hit CGI applications are known for causing.
I know Perl has a lot of detractors, but really you should at least give it a chance before you make up your mind about it. Perl is probably more portable than even Java, and it certainly is better for writing quick scripts and programs. You can make the code very readable if thats your goal, or you can express in one line of code what it would take other languages 5-10 lines to accomplish. Perl/CGI is the most portable way to write web apps so if you do consulting its a good way to go if you need things that will run on lots of different web servers. I've found the neatest libraries for Perl that I haven't seen in any other language - I just wrote a shopping cart that uses SQL to read and write to comma delimited text files! This made for a perfect solution for my client, and it will be easy to upgrade to a real database when he's ready.
Oh by the way if you don't think Perl/CGI can handle heavy duty web sites, look at the slashcode sometime - unless they rewrote everything its still CGI code running under mod_perl/Apache::Registry.
No, Thursday's out. How about never - is never good for you?
..and graduate to the excellent mod_perl cookbook.
php may be more intuitive at first, but it seriously lacks alot of the functionality that comes with other languages like perl and python. while i can only speak for perl, i understand python has a similar component base. perl has cpan which makes php look like a screwdriver in a workshop full of tools. if you only plan on making a web page to take form variables and email them to someone, sure php is great. if you want to make a serious web-based application and you dont want to make everything from scratch then php is really inadiquate.
i speak from expirence here. about a year ago i made the switch from php to perl and i haven't been happier. at the time of leaving the only database abstraction layer was in beta while perl had dbi in a quite stable form.
while i realize the parent was probably a troll, i would strongly encourage people considering php vs (perl, python, etc.) to consider the amount of code already available outside of the base distribution of the scripting language.
-- john
I find a lot of Perl criticism is caused by the lack of a standard framework for CGI applications written in Perl. Other programming languages (PHP, ASP) provided a relatively more confined method for writing your app, whereas Perl can be a treasure chest or a pandora's box depending on your perspective.
There are so many ways to write dynamic Web programs in Perl: embed Perl into your HTML (embperl), embed HTML into your Perl, use a templating system (HTML::Template, Mason, Template Toolkit, etc), mod_perl, and various combinations.
In the end, I think this is a good thing. It means more choices and better adaptability for various situations. However, it can discourage new users of the language that can quickly write CGI programs in Perl, but wind up writing bad programs.
For anyone looking for a Perl CGI framework, I highly encourage you to check out CGI::Application on CPAN. It integrates with HTML::Template, is lighweight, and makes it relatively easy to mod_perl-ify your code if you need performance boosts.
-Will
What next? A review on "Datastructures in Fortran"?
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips