Slashdot Mirror
CGI Programming with Perl
The Scoop Static web pages sufficed back when the web was young. Information flowed one way (like it does on most corporate sites today). Those days are long behind us -- if you want dynamic and interactive content, a whole host of technologies have appeared to fill in the gaps.
Enter Perl and CGI -- the original Swiss Army chainsaw of programming met the standard for exchanging data over HTTP and it was good. Thousands and thousands of programmers discovered this combination of power and simplicity, and the web has never been the same. Now, it's your turn to descend into the mysteries of query strings and stateless transactions, hoping to emerge successfully with the knowledge of simple -- yet interactive -- web programming.
In this second edition, the authors have gone far beyond CGI circa 1996. New topics include XML, search engines, security, and high performance Perl-based alternatives to CGI. How far we've come...
What's to Like? The book begins with an explanation of HTTP. Understanding the underlying protocol gives a picture of the whole process. The same is done for CGI, examing the interface -- the environment, input, output, and headers. It's simple enough that the description never bogs down, but detailed enough to explain difficulties CGI authors must work around (session management being high on the list).From there, it's on to forms and HTML and, before spending much time trying to write a custom decoder for form data, it's off to CGI.pm. (That's important, because it's hard to get this right, even for authors of some other CGI programming books.) As befits the module, this chapter explains handling input, generating output, and handling errors.
Shift gears for a second, and think about embedding your code in your HTML. Try SSI, HTML::Template, or Embperl. (This is just a taste of the techniques available for templating -- see Template Toolkit or Mason for other nice ones.) Following that, grit your teeth and learn some of the JavaScript you've been putting off. Use it to add an additional client-side form input checker, hook it up to your Perl with WDDX, or discover the powerful Bookmarklet.
Consider security in chapter 8 -- now that you've learned some cool tricks but before you know enough to get into real trouble, discover the vulnerabilities and how you can program around them. Use Perl's Taint mode and your web server configuration to help you out. Do not skip this chapter -- read it, then read perldoc perlsec until you get it. (It's a good chapter, but security can be hard, so don't rely on just one source of information.)
The rest of the book is a tour of various tasks you might want to accomplish. They're good too, but things shine again in the last three chapters, with help for the new, curious, frazzled Perl CGI programmer. How do you get rid of that annoying 500 server error? How can you make your program worth using for the next three years instead of worth throwing away every three months? How can you write something that will handle a hundred users a day? A thousand? A front-page link on Slashdot? (The answer is more than just FastCGI or mod_perl, though they're definitely the heavy guns.)
It's definitely time for a second edition of this tome. The expanded coverage of CGI.pm and templating technologies is a welcome addition. Promoting the use of the existing well-tested, documented, and debugged tools will, hopefully, lead to more maintainable code. Unlike some other books, the example code is clean and worthy of emulation. Hit the references and recommendation section in Appendix A for more good information, including relevant RFCs. Really. (It's a good sign for a Perl book to mention both the CPAN and perldoc, as in Appendix B.)
What's to Consider? Be careful about copying code blindly from the first few chapters without reading at least chapter 8 (and perldoc perlsec in Perl's included documentation)! Simple examples are appropriate for teaching and personal testing, but could have disastrous consequences on publicly-accessible servers. To the authors' credit, even the simple example code runs with warnings, taint mode, and the strict pragma.You'll need to know some Perl -- at least enough to follow along with somewhat-idiomatic code. Platform and portability wise, there's an unapologetic Unix flavor to the examples. Nearly everything should work on Win32 and other operating systems, but be aware of certain differences. As for web server information, it's Apache-specific. (Configuration for other platforms will be similar, but is left as an exercise for the reader.)
Some topics could use more treatment. It would have been nice to have more information on HTML::Mason (though admittedly complex, it's powerful and probably deserves more than a two page introduction) and XML and Middleware. New technologies like RSS and WAP need tools and users and programmers. There's also more to say on debugging CGI applications, though a pointer to the facetiously named Idiot's Guide could be helpful.)
The Summary Newly updated, chock full of good advice and, above all, high-quality code, this book is a great place to learn how to focus your Perl skills in a popular direction. Follow the advice presented, ask around for help if you need it, and have fun. Don't bother spending 24 hours or 21 days or whatever it is now, learn CGI programming with Perl the right way.special thanks to the amazing Simone at O'Reilly for her help making these and other reviews possible!
Table of Contents- Getting Started
- The Hypertext Transfer Protocol
- The Common Gateway Interface
- Forms and CGI
- CGI.pm
- HTML Templates
- JavaScript
- Security
- Sending Email
- Data Persistence
- Maintaining State
- Searching the Web Server
- Creating Graphics on the Fly
- Middleware and XML
- Debugging CGI Applications
- Guidelines for Better CGI Applications
- Effeciency and Optimization
- Works Cited and Further Reading
- Perl Modules
If you're more of a do-it-yourself-er, pick languages up easily, and want a more complete Perl reference, get the Camel book (Programming Perl).
If you just want some scripts to copy, look on the web or get the Perl Cookbook.
And if you want to learn advanced Perl stuff, and enjoy extreme pain and an awkward writing style, get Advanced Perl Programming.
I recommend the Llama book, but then, I'm biased. ^_~
srand() is not necessary in perl (as of 5.004, IIRC). rand is auto-seeded, and essentially you get the same seed as you did above without calling srand().
Use the File::Spec module and you don't even need to remember a path separator if it is different. See the perlport manpage for all your portability needs.
I was doing HTTP file uploads when this book was still in diapers! :-) It is just something that hasn't been a priority. Rob already had the code in there, it was just not tested, not used, etc.
As for the unix-specific funtions, what kind of CGI scripts do you write? I've been doing a lot of CGI programming over the last 2-3 years and 99% of the time all the CGI does is take the form input, process it a bit, and stick it in an SQL database (or take data from an SQL database and display it, as the case may be). All this requires is using the DBI module, which is perfectly portable.
I do own my code that I write on my own time. On my employer's time, watch me ask him "Do you want me to spend twice as much time on it to make it portable?" The point is that there are other goals than portability - there's speed, maintainability, ease of implementation (and that *does* matter when the client says "I want it in a week").
If you want to argue that portable code is a basic human right, then obviously, you believe that Free Software (free as in speech) is a basic human right. Since it's possible to make a code unportable (if you have the source and the time), and since it's one reason Free Software is good (you can make stuff faster by doing it in assembly language) - you've hit a contradiction. The way to resolve it is: portable code is merely good, while Free Software is an absolute right (the other alternative, that portable code is an absolute right, doesn't work, because software must be Free to be portable)...
Also, if you get payed for cleaning up unportable code, why are you complaining? Would you prefer to be unemployed?
Become a FSF associate member before the low #s are used
Boy, no kidding. I'm glad I didn't have to learn Perl/CGI just from this book. That, and if I recall correctly, about all that was said about security was along the lines of "Er, yep, security is good. You should write secure scripts." Feh.
---- I'm going to lead you kicking and screaming, giggling and laughing into the future.
Actually, having screenshots from a Windows box provides a ready answer to any questions about whether Perl CGI scripts will interoperate nicely with Windows clients. We know they will. That's the whole point of open, standardized protocols. But for managers who are firmly entrenched in the Windows' Proprietary Standards world, this is an issue. They are used to products that won't talk to the rest of the world. The idea that there is software out there that plays well with others is a new one to them. This may be the way to get your foot in the door.
The net will not be what we demand, but what we make it. Build it well.
I have this book, and it is good, but it requires a larger investment in time then many people who need to whip out a project have.
There's another book I have that's better suited for helping someone who needs to produce a CGI app over the weekend, and that's CGI101 by Jacqueline D. Hamilton.
Check out their website, it has the first few chapters online, and it's really well written.
www.cgi101.com
(I don't work for these people, but I benefited from this book when I needed to get something written from scratch and didn't know Perl or anything abuot CGI)
Having just spent the last month or two messing around with perl on win98 and SuSE Linux I reckon that you're talking crap. I have had next to no problems with cross-compatibility and have found that if i need to make calls to the shell then there is probably a better way to do it within perl. But as I said, I'm not very knowledgeable about the intricacies.
The second thing is that if you are writing something that you can't port without much difficulty then you should perhaps consider writing it natively in C in the first place.
"The new wave is not value-added; it's garbage-subtracted" - Esther Dyson, Dec 1994
I got that book for my web designer girlfriend who had expressed an interest in learning what goes on ``behind the scenes'', and to be honest, after reading it I was way south of impressed. As a resource for the absolute novice to learn the language perl, I guess it's OK (although I still think the Llama book is better). As a reference for the absolute novice to learn CGI programming with perl, it blows monkey ass.
I feel this way becuase it mentions CGI.pm exactly once, in the context of ``it's too hard, just ignore it.'' Uhhhhh.... Yeah. Riiiiight. Programming CGIs in perl without using CGI.pm is about two incrememnts easier than just doing it in C. Using CGI.pm, it's about 100 increments easier. A tiny example is parsing form variables: it's a pain in the ass to get right by hand, it is one very short line of code with CGI.pm (see the param() function). I guess maybe she was trying to avoid mentioning what modules were, but how hard is it to understand that ``use CGI; $r = new CGI;'' makes $r hold a whole bunch of functions and stuff to make CGI easy? You don't have to be an OOP expert to use objects...
Now, I think Ms. Castro's HTML book by peachpit is pretty good. So evidently she just got in over her head or something with the perl book.
--
News for Geeks in Austin, TX
Definitely not. I have and use this book all the time, but I use it for specfic cgi questions and problems. To learn Perl, I wouldn't really bother with a class. I'd just get the O'Reily Perl CDROM bookshelf and start with Learning Perl. This is a good deal, there's six books on the cd that will take you from novice to adept and provide enough quick reference material to solve any problem. The cgi book on the other hand is a great book for someone who's got a pretty good foundation in Perl, but is new to cgi programming.
A web application needs to be tested. You can test it in your own favorite environment, but if you have some unusual hacked up thing (say, Englightenment running on Slackware, with your own private mutation of Mozilla, all with lots of customization) you're just going through the motions. You have test it in whatever environment your users are likely to use: Windows/IE, Windows/Netscape, Lynx, Opera, WebTV. Hey, if your typical user is running wget on Linux/Nintendo, get out your joystick and fire up the virtual keyboard. If you want to lecture the user on his stupidity, fine, but don't pretend that it's part of the design process.
Remember Thorvalds Law: the user is always right.
<RANT>
I'm getting pretty tired of slashdotters accusing each of being "kneejerk", "party line", "PC", etc. That itself is a kneejerk reaction, and a pretty lame one at that. If a post begins by accusing somebody of thoughtcrime, please reconsider. At best, you're being unnecessarily rude. At worst, you're thinking with your spleen.
</RANT>
__________________
__________________
I agree with him on two points: Unix browsers are pretty pathetic. (But I think Konqueror deservers a chance to mature a little.) And 11223 is most definitely a troll, as a browse of his recent posts will quickly confirm.
One question: is "GUNT" just a pun, or does it stand for something?
__________________
Oh come on. You and I use *nix on our desktop but you have seen the numbers we have all seen the numbers. The simple fact is if you take time to look at what they publish and what they put on their website O'Reilly are some of our best friends out there and they put out great books. Yup the screenshots are from winders and macs but guess what most of the people who look at the site that you run on your *nix server are going to be looking at it on winders or a mac. If you have looked at their pages and other books you would understand that this is just pragmatic it shows us where we are at. The website talks about where we can go.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
If you want to support the "*NIX is for servers, Windows and Macintosh are for desktops" party line, then buy this book. If you don't, then go elsewhere with your money.
humor for the clinically insane
great comedy company.
It's not really a Perl book - it's a CGI with Perl book, covering things like JavaScript. If you want to learn Perl get Programming Perl.
OTOH, if you just want a cgi script for your guestbook, you should reject Perl - that is unless you have, and want to learn how to use, mod_perl - otherwise it's very slow. Learn PHP by reading the excellent manual; see also the HOWTO.
Of course if you want to become an expert in some of the seriously sick bits of perl (it's oo functions, etc.), then you'll need a book (not this one though - AFAICT, this book is redundant - wouldbe Perl hackers should get a dedicated Perl book, while everyone else should use PHP or ASP).
Free Anne Tomlinson!!
> unlike with languages like java, you can't always take it with you.
I think you mean 'unlike languages like java, you can almost always take it with you.'
> Going from sparc to x86 and vice versa has always been a headache.
No, there's no problem there, since Perl is a highlevel scripting language.
The only problem is using Unix-specific functions (symbolic links, / as directory separator) on Windows and vice-versa (e.g., using COM).
Free Anne Tomlinson!!
Compared with this, java is nearly un-portable: many environments are still in the migration toward java 2; and parts of the language can be a major headache, even if they work as announced (ever tried to store BLOBs via JDBC in Oracle? ;-)
last not least: Perl Modules are, on the average, very easy to install, and with CPAN there exists a simple method to find relevant modules.
"When do you work?" "Whenever I'm not busy."