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
...when I took my Internet Apps course last year. The book we used was more the size of a pamphlet.
CGI apps in perl, how about perl in CGI? First post Ha.
How ya like dat?
Is this Flamebait? Could you possibly be serious?
What, did I enter a time warp into 1995 or something? Try reviewing something relevant next time, guys.
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.
Who uses Perl/CGI anymore?
Perl int he right hands will wipe the floor with any of those other languages. They may be user friendly for users of vb ... but if you can handle perl the right way you can do more in two lines than two pages of vbscript.
It can be used with databases just as well as php or asp. I use it with interbase and find it very effierent... on a server that would never run php / asp script becuase of the requriemnts...
Cruise TT
Although I love using Perl and am pretty good with it, I don't see why people still use Perl for CGI applications. I've grown accustomed to using PHP for all of my web apps and stick to using Perl for system administration tasks and in cron jobs that populate my databases. With languages like PHP, Python, and Ruby, why would someone still use Perl for CGI? I guess 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, and on which one of these other languages isn't available.
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
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.
As a "girl" I take offense to that comment. Find a creative, non-sexist way to put down a programming language next tim.
Yup
-- Serge K. Keller
asp and php are better for pages that are primarily static text. You can write the static html as static html, and just enclose the custom content code in tags.
Much cleaner than
cat
- 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."
I have been trying to get rid of some old perl code that our marketing department contracted. I would say that it is rather well written perl code, but it is still unmaintainable due to it's ugly syntax. It is time to let perl drop away, it is no longer needed and is not a enerprise suited language.
Got Code?
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.
Can you read it with a microscope?
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.
You don't need to be a Kreskin to predict Perl's future. The hand writing is on the wall: Perl faces a bleak future. In fact there won't be any future at all for Perl because Perl is dying. Things are looking very bad for Perl. As many of us are already aware, Perl continues to lose market share. Red ink flows like a river of blood. ActiveState is the most endangered of them all, having lost 93% of its core developers. ;-)
Funny, thats what my MS lovin' friends say about my programming in C++ for Windows. Know what? With all this CLR they might be right... Scarey thoughts are running through my head. Good thing I got several linux distro's ready to go.
Reserved Word.
Speaking of security www.cgisecurity.com is worth a peek for those dealing with weba pplications.
Sorry about everything being in italics. I was adding something near the end and deleted the HTML close for italics on accident. Post starts at Funny.
Reserved Word.
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...
Nice try at a troll there son. Just because you wear a dress and high heels doesn't make you a chick, dude.
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.
As much as I enjoyed writing perl CGI in my day. I find that PHP is much more suited to my current purposes and produces quicker, more readable prototypes. I mean, how am I to explain web page generation in perl to someone? Now I grab someone's pre-existing page with all of the art and stuff in tact, and add in a couple dynamically generated fields that pull data from a database.
"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.
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
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.
CGI Programming in C & Perl, by Thomas Boutell. I used this book for an independent study course that I taught at a University (way back in 1997). Definitely gives you a thorough understanding of what is going on in the CGI process. I found the examples, which are in both C and Perl, to be very helpful.
come on fhqwhgads
I found that most of the struggles I was having with Perl were because the ORA books (and I have nearly all the perl ones) are not really that good. Some of them are, but the beginner books most definately are not. An example is the Coriolis Perl black book. You'll learn a damn sight more with that one that "learning perl" or "programming perl". Also, the Roth books are way better for Win32 perl. But that's another kettle of bananas entirely ....
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 have started developing all of my server-side and web apps in Java, and think it is a fairly easy, powerful language to use. However, it seems like I read through the comments and Java seems to always be LOW on everyone's favorite language list.
Is this because it came too late? But I would think PHP came later. Or is it because no one wants to learn another language if they already know C++ and Perl? I personally don't have much use at the moment for C++ (but see it's importance in some things over Java like game development) and only use Perl if I'm writing scripts to learn more about Unix - Just curious why Java seems so hated.
Let's face it, you're not going to some
intensive number crunching in PERL PHP ASP whatever.
You're going to CGI to a C program.
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 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.
It's a good book? What, is the only text in it "Use something else, like PHP, Python, ..."?
..and graduate to the excellent mod_perl cookbook.
I find the way you put "girl" in quotation marks rather disturbing.
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.
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.
It's amazing how emotional people get in their resistence to this wonderfully simple and handy security check. See this discussion for an example of the lengths to which people will go to avoid putting a simple T in their code.
Miko O'Sullivan
why in the world would someone sit there and write a shopping cart or other complex dynamic driven site in Perl? Perl is so unmaintainable and unportable. I personally use CF for all of my applications. It's ALOT easier and faster to develope in then Perl. Plus with the version for Linux, it is easy to port to the other enviroment. Perl is a dead language. With all of the other better and smarter choices to choose from to develope with, why bother with Perl?
That's way too big for the subject. As someone else remarked, much of it is big margins, big type, repetition, duplicated code listings, and fluff. This whole subject should be covered in no more than 100 pages.
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
That's why you abstract your code out, database connections in one file, html headers/footers/boilerplate in one, javascript libraries in another. Using slash as an example, users.pl, index.pl, comments.pl, and metamod.pl, all make calls to other code sources to generate page layout, database connections, and other features. Yes PHP (or SSI/Embperl or ruby, or python)can be used for "I need to generate a single table from my dbase in this monster page, I'll just throw a mysql_connect here, a echo there and I'm done", but it also can be done in a highly modular way.
09f911029d74e35bd84156c5635688c0
Java no more has the web and network as a core functionality of the language than perl does. They're both a function of a) the environment in which the code runs, and b) standard libraries.
Java is just a somewhat OO C-family language, otherwise. It's the libraries that give it network and web functionality, just like perl.
Now, it might be arguable that the java libraries and integration of the java environment into web servers is better than the perl libraries and perl integration into web servers. So make that argument!
This book would have been totally sweet in 1996 when 'Perl' and 'cgi' were the best solution.
Who are you people using Perl? And why? Perl monkeys can't be trusted to make CGI's -- they're too likely to leave security holes.
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.
Why not read the review before commenting first next time?:
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.
This is going to go down like a cup of cold sick, but...
If you do this sort of thing for a living, it would pay to look into alternative tools that make your life easier. For instance, check out the available Haskell web/CGI/HTML/XML libraries. Coding plain and interactive web interfaces that are rock solid is so much easier it's not funny. A whole raft of bug classes are simply impossible using these schemes.
By the way, before anybody says otherwise, Haskell is a serious, full-blown industrial strength language.
I am fluent in all these langauges and several others. I have written CGI/Mod scripts in all, including C/C++ and Java.
CGI is SLOW. There is now way around it. The perl _interpreter_ just takes too long to load to take seriously on any site that has a high throughput. mod_perl has memory leak issues, and just isn't for the faint hearted.
We don't need more books on CGI/Perl. We need more people lobying web hosts to have mod_python/PHP available.
So many people complain that PHP lacks templatization capability. it has include(), and it has a very good, and simple to implement XML parser that allows you to generate a very powerful template system. I know because I've built one, and I work for a web application design house, that doesn't do anything much under $10k jobs. We are a pure Linux/Solaris shop.
PHP has the best documentation in a centralised location. Perl doesn't, and neither does Python. I would much prefer to use mod_python, but documentation on python is difficult and confusing compared to PHP for junior developers.
You can certainly do more in Perl than PHP, but Perl faster?!! *rofl* that's a good one. I have built enterprise class websites in PHP for several years, and I have never once had a major problem with it's ""Lack of features"". It does everything you need, and more. The only problem with PHP is writing non CGI/Mod scripts. For that it sucks. I use Python. Perl has a poor OO model, and it's very slow. Perl is not a peach to debug, python has exceptions which rule. Python has been shown to be as fast as C++ in several benchmarks. It's garbage collection works, unlike Java which still seems to have issues.
One of our key products that is a very intensive search app outperforms every other company on the web today. It's written in PHP and Postgresql. Those other sites are mostly running Microsoft SQL Server with ASP, an ""Industry Standard"" on database machine four to eight times the size of ours. Please don't tell me PHP isn't mature enough, or featureful enough, thats crap. I hate the fact that it's not GPL, and I don't like it's object model, and I don't like some of the naming conventions. But it has the best documentation by far, and is the easiest to use. When you can produce a $27k website in two and a half weeks because it's that easy in PHP, what more can you say. I know Perl applications that were just so bogged down in variable issues, and namespace problems that they became unmaintainable, and lost the company they were written for real money, which could have been avoided if the project had just used a real language like Python or C++.
Perl is a great language for hacking up a text processing thingie, or a migration script, or any one of a hundred other small things. But you can't write serious apps in it. They are unmaintainable once the primary programmer disappears because everyone has their own Perl style, it's like Stravinsky trying to finish a piece of Mozart.
Everyone is living in a personal delusion, just some are more delusional than others.
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