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.
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.
"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.
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
Hate to sound like a "*BSD is Dead" troll, but CGI is a dying breed...
But it will never go away entirely. For a lot of simple things CGI is quite appropriate. At work, we have a feed monitoring utility that just generates tables of timestamps. I have very rarely seen it fail. And when it does, it doesn't happen twice in a row unless there's something wrong with the database or the web server. For something mission-critical like your feed monitoring utility you don't want some stateful enterprise application amorphous cloud super server to get it's tentacles in a tangle. CGI is very easy to use, understand, and debug. Don't rule it out alltogether. It's just a tool for niche stateless applications.