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.
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)
For a while there I was giving ASP a try. But 80% of the time, I would do the little project in ASP, and then a couple weeks later I'd get a request for more and more advanced features which were either impossible in ASP, or much much more realistic in a real Perl CGI application. Inevitably I'd have to rewrite the application in Perl for any real power.
I'll stick to Perl CGI.
"And like that
In the long run, though, you'll find that Apache::Registry is not the Better Way to do it... either .pm modules with tiny bits of front-end code for the handlers, or (IMHO) PHP with the same approach (class libraries or .so extensions in C). I chose PHP after a protracted battle and some development in both. PHP is slower than mod_perl for execution, but faster than either for development (assuming you push any nasty complex code into either C, classes, or classes calling C). Even with Inline.pm, and even after 4 years of writing Perl for web apps, I've finally sworn I'll never write another line of interface code in Perl. Backend? Sure. And reading the Eagle Book is a great way to get comfortable with how Apache actually works. But I've had enough of Perl on the front end, and if you look around, so have most other people.
Not a flame, just an observation. Apache::Registry is not a panacea.
Remember that what's inside of you doesn't matter because nobody can see it.
I've done a lot of web development, in a variety of languages. I've been working in the ISP sector since 1993 - I wrote tools and utils for AmiTCP in-between increasing the dogearedness of my pink-cover first version camel book.
PHP suffers from the same issues as JSP when it comes to building webapps and toys. It's also not really the most efficient system around either.
Much as I love Perl, and have always enjoyed knocking out CGI systems - including one of the first "fansite"s which offered people free custom emails and URLs (warbirds.org), and I've had lots of fun with PHP, I have personally found Roxens built in RXML mark-up language to be one of the most efficient systems for developing web applications in terms of design, implementation and operation.
Roxen was born "Spinner" back around, if not before. In all those years since, I've yet to find a good or compelling reason to use Apache, Perl or PHP instead of Roxen beyond the head-count factor. The Roxen developers make their money through 'value adding' their open source webserver platform, but never really tried to market themselves.
-- A change is as good as a reboot.
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.