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.
Yeah, that's covered in great depth the section on security that I mentioned in the review.
Oh, nothing. It's just that I would rather not have had it presented as the only templating solution.
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!
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
-- Sorry, I can't think of anything funny to say here.
- 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.
Oh my god, you're right. Perl5 has a horrible syntax, a really slow runtime, and had lots of really bad design decisions as it evolved. You know what we should do? We should start again from scratch design a new language and a really fast virtual machine. Oh wait, we already did...
My prefered solution is actually HTML::Mason, which gives simple embedding of perl code & components into webpages. However, CGI.pm and Apache::Registery is the most portable solution, as it gives a program that can be run on both CGI & mod_perl enabled webservers.
I have this book. I found it very useful, but lacking in some ways. The authors advertised this book as not merely presenting code, but the concepts that underlay what is going on. I found this book to be primarily a bunch of recipes...just the opposite of how it was advertised. They present alot of topics and I found the breadth of this book to be very good. I do feel however, that many subjects that were addressed were incomplete. For example, in the chapter on databases, they present the SQL function calls that they need for their example, but don't even provide a list of the interface functions to write a more general application. "How about telling me how to update an existing record?". I bought this book with a little exposure to perl, and less exposure to developing websites. I found that for most topics that they presented, I needed to track down additional documentation to do anything different then what was presented in the book.
I did find the information on mod_perl, HTML::Mason, and RSS to be especially interesting.
If you are looking for an introduction to developing web apps with perl this book presents a large number of technologies, and does a pretty good job. It definitly is not a reference, however.
I'd agree that the mod_perl Developer's Cookbook is really good, and you'll have to prise it from my dead hands before I'll give up my copy.
-- Sorry, I can't think of anything funny to say here.