Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Perl Books Media Programming Book Reviews

mod_perl Developer's Cookbook 80

davorg writes "Over the last few years mod_perl has become a serious force in web development. If you're building a web site to run on an Apache server and you want to write the code in Perl, then you're going to want to install mod_perl on your server too as it's the best way to avoid many of the performance issues with traditional CGI. It's taken a while for publishers to wake up to the fact, however, and there haven't been many books in the shops. It looks like this will be the year that this changes. A number of mod_perl books are about to be published and this is the first." Read on below for Daveorg's thoughts on this one.
mod_perl Developer's Cookbook
author Geoffrey Young, Paul Lindner & Randy Kobes
pages 630
publisher Sams
rating 9
reviewer Dave Cross
ISBN 0-672-32240-4
summary What mod_perl programmers have been waiting for

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 Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

mod_perl Developer's Cookbook

Comments Filter:
  • by MrBoombasticfantasti ( 593721 ) on Wednesday September 18, 2002 @10:03AM (#4281019)
    It doesn't actually add much to the info already available at CPAN. Still nice to have it on the shelve.
  • by cperciva ( 102828 ) on Wednesday September 18, 2002 @10:31AM (#4281204) Homepage
    Even C cannot dynamically generate a file as fast as it can be read from disk.

    That depends upon what the file is, and how fast your disk system is. Many large scientific computations which, in the past, precomputed values and stored them to disk now recompute as necessary, simply because the recomputation is faster than a disk access.

    You won't be able to regenerate a file as fast as it can be read from cache; but unless you have an infinite amount of cache memory, there are likely to be cases where you're better off to recompute and allow something else to be cached.
  • by Glorat ( 414139 ) on Wednesday September 18, 2002 @11:09AM (#4281477)
    Actually, one of the barriers to mod_perl use is that mod_perl by default does *not* provide transparent wrapping of CGI programs. It can be made to do so using PerlRun modules but I think it's just a case that a documentation needs to be more prominent about this fact that vanilla Apache::Registry scripts behave significantly different from CGI. Perhaps the documentation should advertise more the PerlRun modules (etc) that do give transparent CGI wrapping. I like many others have fallen into the trap of just blindly switching a script from CGI to mod_perl and bitten by many of the (documented) issues if you bother to RTFM which of course I didn't at first =)

    Now that I know mod_perl indepth, the parent is correct in the immense flexibility of mod_perl with its ability to directly interface with Apache. Something you won't be able to do ever with CGI or even PHP.

    And about You can write whole content management systems using mod_perl, and in fact many have. Of course the CMS running here at Slashdot is powered by Slashcode [] which runs under Apache/mod_perl.
  • by gorilla ( 36491 ) on Wednesday September 18, 2002 @11:22AM (#4281556)
    An example of one of these content management systems would be mason, [], and mason apps such as Fuse CMS [] and Bricolage []. I find Mason to be just as powerful as multi-thousand dollar applications such as StoryServer []
  • by bitpusherdotorg ( 544243 ) on Wednesday September 18, 2002 @06:11PM (#4285047)
    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.

The other line moves faster.