Slashdot Mirror
mod_perl Developer's Cookbook
This book uses the popular "cookbook" approach, where the content is broken down into short "recipes" each of which addresses a specific problem. There are almost two hundred of these recipes in the book arranged into chapters which discuss particular areas of mod_perl development. In my opinion the cookbook approach works much better in some chapters than in others.
It's the start of the book where the cookbook approach seems most forced. In chapter 1 problems like "You want to compile and build mod_perl from source on a Unix platform" provide slightly awkward introductions to explanations about obtaining and installing mod_perl on various platforms (kudos to the authors for being up-to-date enough to include OS X in the list). All the information you want is there however, so by the end of the chapter you'll have mod_perl up and running.
Chapter 2 looks at configuration options. It tell you how to get your CGI programs running under mod_perl using the Apache::Registry module which simulates a standard CGI environment so that your CGI programs can run almost unchanged. This will give you an immediate performance increase as you no longer have the performance hit of starting up a Perl interpreter each time one of your CGI programs is run. This chapter also addresses issues like caching database connections and using mod_perl as a proxy server.
We then get to part II of the book. In this section we look at the mod_perl API which gives us to the full functionality of Apache. This allows us to write Perl code which is executed at any time during any of the stages of Apache's processing.
Chapter 3 introduces the Apache request object which is at the heart of the API and discusses various ways to get useful information both out of and back into the object. Chapter 4 serves a similar purpose for the Apache server object which contains information about the web server and its configuration.
In chapter 5 the authors look at Uniform Resource Identifiers (URIs) and discuss many methods for processing them. Chapter 6 moves from the logical world of URIs to the physical world of files. This chapter starts by explaining the Apache::File module before looking at many ways to handle files in mod_perl.
The previous few chapters have built up a useful toolkit of techniques to use in a mod_perl environment, in chapters 7 and 8 we start to pull those techniques together and look in more detail at creating handlers - which are the building blocks of mod_perl applications. Chapter 7 deal with the creation of handlers and chapter 8 looks at how you can interact with them to build a complete application.
Chapter 9 is one of the most useful chapters in the book as it deals with benchmarking and tuning mod_perl applications. It serves as a useful guide to a number of techniques for squeezing the last drops of performance out of your web site. Chapter 10 is a useful introduction to using Object Oriented Perl to create your handlers. While the information is all good, this is, unfortunately, another chapter where the cookbook format seems a little strained.
Part III of the book goes into great detail about the Apache lifecycle. Each chapter looks at a small number of Apache's processing stages and suggests ways that handlers can be used during that stage. This is the widest ranging part of the book and it's full of example code that really demonstrates the power of the Apache API. I'll just mention one particular chapter in this section. Chapter 15 talks about the content generation phrase. This is the phase that creates the actual content that goes back to the user's browser and, as such, is the most important phase of the whole transaction. I was particularly pleased to see that the authors took up most of this chapter looking at methods that separate the actual data from the presentation. They have at recipes that look at all of the commonly used Perl templating systems and a few more recipes cover the generation of output from XML.
Finally, two appendices give a brief reference to mod_perl hooks, build flags and constants and a third gives a good selection of pointers to further resources.
This is the book that mod_perl programmers have been waiting for. The three authors are all well-known experts in the field and it's great that they have shared their knowledge through this book. If you write mod_perl applications, then you really should read this book.
You can purchase mod_perl Developer's Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It doesn't actually add much to the info already available at CPAN. Still nice to have it on the shelve.
!ERR: Signature not found.
mod_perl provides a means for transparently wrapping CGI programs so that they run continuously instead of starting up (and thus parsing) every time a request requirest them.
However, it's much more than a CGI accelerator. It provides hooks into all of the stages of an apache transation.
As an example of the kind of power this gives you, you can write a Perl plugin for Apache that intercepts 404s, and generates a dynamic page which you then cache to disk for future access (far out-stripping even native C dynamic page generation speeds on subsequent hits). This is just one example. You can write whole content management systems using mod_perl, and in fact many have.
we (the authors) support a companion website where you can find a number of useful items, such as all the code from the book (to save your fingers) and a full-text search engine (to supplement the index).
http://www.modperlcookbook.org/
enjoy
PHP is fine, but it's not as fast as mod_perl.
[disclaimer: author post follows]
The problem with CPAN is knowing what's useful and what's not. This book isn't just a collection of modules and documentation. Instead it's geared to people who are writing mod_perl code. The code examples are used to show you not just how to do some task, but also (in most cases) how the code does what it does.
In fact, distilling mod_perl code into short, sweet examples was where most of the effort went into writing this book. You don't want pages and pages of code to illustrate one or two simple ideas.
So, perhaps we didn't write a book that was useful to you. Given the feedback I've read, it is useful to many other people.
it's taken /. a while as well; this book was published in January
In any case, it's nice to see a new review on one of my favorite web sites. More good reviews over there at amazon and at the book's official web site.
It's partly my fault. I got my review copy in June :-/
http://www.modperlcookbook.org/modperl2.html
One thing to note is that it is for the 1.3 version not the new 2.0 version. They say though there are not too many differences.
This book's approach helps me find tried and true approaches to the things I need to make mod_perl do. It's far better organized and written than the freely available documentation and covers a range of modules (many written for the book) that do things I used to do the hard way. It's clear, concise, and the material is well chosen. You'll get a lot further along on your next mod_perl project a lot faster with this book close to hand than by repeatedly scouring CPAN and the web for the modules, mail messages, and documentation
Yours in mod_perl,
Barrie
I don't think so. Mod_perl gets its hooks so much deeper into Apache than CGI does, that it's hard to share.
One problem is that a bad mod_perl program can bring down the server. A bad CGI program can't since by definition it's forking a new process to run, so all it can do is crash its own forked process.
Another issue is that in order to load new or modified mod_perl scripts, you need the privileges of the process running the server.
No way you can do that in a virtual hosting environment, unless you have a death wish.
In order to install a mod_perl script you also have to be able to edit the apache config file. Typically (for good reasons) a file writable only by root.
Another issue is that the apache processes running keep all the mod_perl programs in memory. If there were ten different mod_perl-enabled "web sites" run by the same apache server on the same box, that could get really inefficient.
More I think about it, the only way this could work is if each mod_perl virtual host has its own apache server instance, with full ownership of its own config file and privileges to bring it down and restart it.
You would need some kind of gateway server answering all requests coming in to port 80 and redirecting them to a different port depending on the request's URL; each mod_perl virtual host would have its own port number which the gateway server would redirect to.
This sort of internal redirect is often used now running a server without mod_perl to handle static requests, and a mod_perl-enabled server to handle dynamic requests on the same box.
-->So I have changed my off-the-cuff conclusion. You could do this all on one box, but it would be complicated, and a fundamentally different model than shared hosting with CGI only. And I'm not sure any hosting company is doing it. Nor am I sure that there aren't some bad security or performance implications I haven't thought of.
Just get DSL and start messing around running mod_perl on your own computer. If it's a low-volume or self-instructional site that should be quite adequate.
Maybe obfusgated(sp?) code. My perl looks just as good as my C/C++. I've never had a problem reading the perl of others, either, provided it was formatted and commented with just a little care.
Finally, math books without any of that base 6 crap in them.
True, Perl doesn't have to be messy. It's all a matter of coding style. If you are a considerate developer, you will write clean, easy to read code that's replete with useful comments.
Unfortunately, there are people who want to write messy code out there, and I'll be damned if I have to maintain it!
Thanks for the point - clarity of code is a matter of style, but certainly the choice of language helps as well.