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.
I found sams Teach Your Self Perl in 24hour very good as a starter.... (isbn 0-672-31773-7)
got all the basics and enough to start on cgi... evan if you don't know perl to start with...
Cruise TT
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.
As I said in another post, since you can run Perl CGI scripts in mod_perl (i.e. with perl built directly into Apache itself) the stuff covered in this book is still quite useful. Many powerful sites (including this one) use mod_perl, and it's a good skill to learn...starting off with CGI programming is one good way to start to go about that.
-- Sorry, I can't think of anything funny to say here.
ColdFusion for large apps? Now that's a scary thought.
Because Perl is more powerful and faster than PHP? Perl is a far more developed language than PHP, Python, or Ruby.
.NET, VB.Net is as powerful as VC++.NET, but that never used to be the way ;-)
;-)
Translating your question into client side programming speak:
"Why use Visual C++ when you can just use Visual Basic?"
Of course, thanks to
Perl is a powerful language with far more backing than PHP, Python, or Ruby. The amount of modules you can get for Perl makes it a very wise language to use if you want to do anything advanced.. i.e. XML-RPC, SOAP, image manipulation on the fly, system integration, etc.
PHP cannot do many of these things well.. and it cannot do them very quickly. PHP is a toy language for kiddies who are still playing with MySQL databases
mogorific carpentry experiments
For a bunch of secure well-written CGI programs for specific tasks, you can't beat nms. Hope this helps.
"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.
Seems to me, a few people claim that Perl is no good for writing dynamic Websites...
Erm.... Slashdot seems to work and scale pretty well to me - thats written using Perl.
Sure if you're using Plain old perl/cgi then fine...but have you guys never heard of mod_perl..
PHP is good, but have you ever tried to maintain it....Anything other than simply "noddy" sites becomes a real pain in the ass....
The idea of mixing Logic and HTML output is a big no-no IMHO
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.
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.
100 pages? Sure, we could have done, but then nobody would ever *learn* from the book.
This book was designed to be a learning tool, with practical examples.
My goal with the writing that I did was to provide concrete examples people could use and learn from, directly. I have seen too many books that show a concept and then explain a bit about it, but NEVER really show you how to duplicate it. Instead, every line of code is explained so that the reader can see how and why it works.
Sure, if you are comfortable with Perl and writing CGI's, this book is probably not for you...
Also, those people saying CGI's are dead. Um, heh, ok - think what you will...
Brent
-- Windows security? Sure, which ONE would you like? -me
For all the PHP zealots out there. Yes, I too like PHP, it has many good features.
But, I find that if I want to do dynamic content, HTML::Mason is much better (for me at least). I can embed the Perl right into the HTML, plus Mason has a lot of other nice features that make it worthwhile.
Plus, I am having a lot of fun reading all of the comments generated by this discussion.
It really amazes me how people basically say things like "Well, I use X for this so everyone else should too"... The key to being a good web developer is using the right tool for the job AS WELL AS utilizing the tools available to you. you also need to take into account what you are better at. I am a Perl developer, sure, I could choose to write apps in C, Java, PHP, Ruby, whatnot, but then I am not utilizing MY talents to their fullest.
Lots -O- flame-bait in these discussions, that is for sure...
Brent
-- Windows security? Sure, which ONE would you like? -me
I don't care how ugly $, @, etc. looks I'm damn glad Perl, PHP, and friends use special characters to dilineate variables! When you scan through code in something like C often times it's not so easy to figure out just what's what, what's a function, what's a variable, what's some gawdawful clever #define dohicky, etc. I'll take ugly and understandable over pretty and incomprehensible any day.
--
He lied to us through song. I hate when people do that!