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
It's good to finally see a CGI/Perl book pushing strict and warnings. Of course, that's not going to ensure good programming, I've seen some horribly stupid code pass the test with use strict;. Do they use Taint mode at all? Is there any mention of how dumb CGI can be, and the nasty pits it can leave when problems (not obvious to the new guy, like unchecked open filehandles) are ignored?
Also, what's wrong with Mason? They may have recommended it because it makes an easy transition into mod_perl, as it can be used either way.
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.
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.
- 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."
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
...is the best way to eat all the memory on a server and end into a complete freeze. That's what I can see everyday on servers running different CGI apps written in Perl. On the other hand, PHP is fast and doesn't eat your memory. Of course I'll be answered that well-programmed Perl CGI apps don't eat the memory. Maybe, maybe not. The fact is I can see all those Perl CGI apps designed by more or less experienced programmers, and all those PHP apps designed by the same people. And the consequences of each ones are (very) different.
This is a big one for me. As a programmer, it has become increasingly difficult to compete with hackjobs out there. Anyone can pick up a book and begin writing Perl CGI or PHP websites, but not everyone has the experience to secure those systems, or to identify bad code design that leaves built-in vulnerabilities. With some companies this is hard to convey -- well, when you are proposing a $25,000 solution and there is another company willing to do it for $5,000. Nevermind that they have two programmers on their staff willing to make $20,000 this year each and they have been programming off and on for a couple of years, but they like making web pages!
Click here or 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.
Perl combined with a good template parser and you have the best tool for developing web apps. Perl is fast, stable, powerful and ubiquitous.
The primary mode of PHP development is to mix code within your html. This works for small or single purpose applications but sucks if you want to develop a server app that uses several different sets of templates customized for different users.
"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.
The book takes 6 chapters to get to mod_perl handlers. In that span, Stein and Eachern have already:
1) shown you how to fit the pieces of Apache together,
2) written sample code for 3 of the 7 standard phases of the Apache request cycle, and
3) actually given you some insight into how to extend Apache for other purposes.
Lincoln used to write CGI scripts. He wrote CGI.pm, in fact. Don't you think the fact that he wrote his most notable programming book on mod_perl is a telltale sign of what I find wrong with this book AND the review?
And that witty riposte -- my god! I've never in my entire life heard that one before! Quick, somebody get Jerry Seinfeld's agent on the phone.
I can be 'arsed' to read an article and (gasp!) form an opinion about it based on my own experience... 7 solid years of it, in this field. And looking back (with the current toolset) I would not want to see ANYONE start off re-inventing the wheel with Perl CGI scripts. Hell, if you're going to re-invent the wheel, at least make it round. CGI is, was, and will always be a kludge. Apache::Registry is a kludge to shoehorn CGI kludgers into the Better Way. Personally, I'd rather see people start out with PHP, because even if their code looks like trash, at least I can write a parser to fix it.
End of rant.
Remember that what's inside of you doesn't matter because nobody can see 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...
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.
which is another huge win for that over Perl (either CGI or mod_perl). For simple web applications PHP crushes Perl (and yes, I was a Perl loyalist for 4 years, resisting the inevitable until about 2 years ago). For back-end stuff you don't need mod_perl.
I don't see the point of CGI anymore.
Remember that what's inside of you doesn't matter because nobody can see it.
O.K. lets compare syntax. List what you consider to be hideous Perl code and contrast it to comparable code in your language of choice. Chances are the syntax is not what is making the code unmaintainable but bad design or your unfamiliarity with Perl or programming in general.
"Another fine O'Reilly title" is still often redundant. Even if not Excellent, they are often Very Good, or at least Good Enough, and I've only once encountered one (on UML, and it's long out of print) that was Mostly Useless. I trust the brand. Often I can't wait weeks to months for the reviews to come out before I buy a book. So I buy the brand I trust.
Best Slashdot Co
I agree -- the mouse book rocks! The part on CGI debugging is particularly good. Not only that but the first edition is free in digital form.
Find free books.
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.
I can't comment on your specific example without seeing the code, but at least in my past experience, it is possible (and relatively simple) to do this with CGI.pm.
However, it's even simpler (and faster) with PHP and that's one reason why I switched. When I first started using Perl for CGI scripts I wrote my own damn CGI %ENV{$foo} de-HTTP-encoder and for the longest time I couldn't understand why CGI.pm was so bloated (truthfully, I kind of still don't). But if you only use specific methods (use CGI.pm qw (foo bar baz); ) then it works OK.
Like I said, I switched to PHP for this and other reasons. I still use Perl on the back end, but for volatile user-interface code, it's all PHP. I think it's a maintenance trap to use Perl if you're ever likely to hand the code over to another engineer, or (worse) do something else for a few months, then come back and try to extend it.
YMMV.
Remember that what's inside of you doesn't matter because nobody can see it.
I implemented a storefront that depends on a business partner's calendar (for video feeds). Between LWP and the XML::Parser module that I fed the massaged LWP output into (thanks to your chapter on using the module, it took me about an afternoon to write), and a transactional update facility in the Postgres backend, we've made well into the hundreds of thousands off it. With Yahoo! Store, not only would we be forking over cash for hostage each month, but the presentation options aren't sane enough that any of the networks would buy (at least not at current buy-rates).
;-)
So, in the span of an afternoon, and over the next few months, my design + your book made us a large pile of cash. Ask someone at CNN, C-SPAN, NBC, FOX, or Bloomberg how they like the interface...
Remember that what's inside of you doesn't matter because nobody can see it.
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 has better (read: more secure) ways to do calculations using outside programs outside of the cgi layer.
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?
I was comparing PHP with CGI. Not PHP with perl. I call several perl scripts from within my PHP programs using exec() and passthru() which are IMHO more stable and secure than the CGI layer.
...and is not a enerprise suited language.
What, pray tell, does this mean? I have heard people tell me that they thought that perl was not "enterprise ready." When I asked them what that meant I got highly-subjective and conflicting answers.
Is the charge that perl is not "enterprise ready" just manager-speak for expressing the prejudiced opinion that perl is merely a "hacker tool"?
I don't make the rules. I just make fun of them.
..and graduate to the excellent mod_perl cookbook.
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
What next? A review on "Datastructures in Fortran"?
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Our own http://www.logicreate.com product is an example of a complex system which makes PHP development of large scale projects easier than you'd think, based on the tediousness of most online PHP tutorials.
:)
Yes this is primarily a shameless plug, but rather than just saying 'PHP is not a toy' I figured I'd give an actual example.
creation science book
You can call me a twisted pervert, but I just can't wait until I sit in front of my future Debian GNU/Hurd 4.0+ system to hack some insane Perl 6 code, drinking espresso and listening to The Ride of the Valkyrie of Richard Wagner...
Krótko: kady Erotomek
W pimiennictwie ma swój domek.
while i prefer perl. i believe you can get alot of the same flexability from python.
-- john
I didn't realize it was ActiveState Perl. That's good. PPM is pretty good, from what I hear.
Secession is the right of all sentient beings.
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
Why do I write CGI with Perl? You said it yourself. "I love using Perl and am pretty good with it." If given the choice between spending my time learning a new language or spending my time writing scripts in the language I know, I'll chose the second.
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!
I'm not sure I'd class Perl as being elegant. It's very overcomplex and convoluted to my eye.
Simple things like creating classes, passing large data structures about, gracefully handling error situations, even handling argument lists for subroutines, all require either too much code or too many
I do admit to seeing some degree of elegance in the whole @foo[] thing, but I'm growing increasingly alergic to touching native data structures directly, so the use of syntax to denote context and type is rapidly loosing it's appeal.
That's not to say I hate Perl, but I do find myself using Ruby for almost all the situations I'd normally use Perl. The resulting code is usually at least as concise and much cleaner. I can't say I miss it, but I don't hate it's very existance like I do VB
mod_php transparent to the PHP code. No calls to Apache::Registry, no use strict; no difference whatsoever. Therein lies the advantage for people who are hosting with a provider. And most providers have mod_php running, or will set it up for you (pair.com for example). To run mod_perl you're looking at a dedicated server for sure.
I have no idea what you've been doing with php, but to claim that mod_php is "like mod_perl" is one of the most ludicrous things I've recently heard. The only way mod_php is "like" mod_perl is that it's an Apache module (most of the time...).
mod_perl is much more powerful (and dangerous).
PHP code running under mod_php is SLOWER than a mod_perl handler. The big win comes in terms of development and maintenance (and portability).
If you want to use Perl, please do so, but don't go implying that mod_perl's functionality is identical to mod_php. That's very misleading.
Remember that what's inside of you doesn't matter because nobody can see it.
if curly braces and semicolons make java a part of the C family, then glasses and bad haircuts make linus and bill gates brothers.
Puctuation does not make languages similar!!!
Read my clarification if you have a problem with what I wrote. I never claimed that the book didn't address mod_perl. I claimed that a book which focuses primarily on CGI and CGI-style applications is irrelevant. And (at least IMHO) it is.
Remember that what's inside of you doesn't matter because nobody can see it.
The fact that Java is not free software rankles a bit too
Well, Tomcat is perfectly free.
As far as strong typing and strings, if you aren't using a strongly typed language you are doing a tremendous amount of debugging by hand that should be handled by your compiler. Also by disregarding Java you are also throwing away a tremendous body of web related libraries and frameworks, plus support facilities like JUnit and JMeter that are part of the Apache Jakarta project.
Finally, if you want the ultimate reason, do a job search and look at the number of Java positions vs. Perl positions.
I agree that a lot of people underestimate PHP, which is excellent, but it is a tool for a job. imho it's for small to medium-large projects. I'm not sure I would recommend it for a seriously large project though.
Phillip.
Property for sale in Nice, France