in reply to OO CGI Engine
I would suggest thinking about moving away from CGI for a large project. There are a number of good "templating" tools that allow you to divide a web application up into sets of "components", each of which can contain HTML, Perl or both.
Our business is building very large web systems, and we use HTML::Mason on every project. Mason is stable, clean and has a number of nice features such as the ability to selectively/flexibly cache components/pages. But most importantly, using Mason doesn't limit your ability to write as much complex Perl code as you want. Anything you can do in a standalone program, you can do in a Mason component. And you can (and should) abstract out core logic into app-specific modules and 'use' them from your various Mason pieces. For big projects, this "embedded perl" approach almost always ends up being a much more efficient way to do development than the "shortcut-to-HTML" approach that CGI relies on.
As far as "engines" go, you might want to look at the platform we developed over the course of the last couple of years: XML::Comma. Comma allows you to model all of the bits and pieces of "information" that your app uses as "documents," which can then be manipulated, stored in the filesystem, broken apart and stored in databases, transferred across the network, etc through a single API. If you tend to design applications using "quasi-hooks" and run-time dispatching, you'll probably love Comma. Most every part of the "life-cycle" of a Comma doc is hookable.
We started out two years ago to build a temporary, XML+Perl platform that we could use until the various critical XML specs came together. At some point, we realized that even when XSLT and friends become fully usable, we'll still need a more job-specific framework for the kind of work we do. So we've continued to rewrite/develop/extend that original platform. Last month, I finally finished a complete programmer's guide to Comma, and now we're looking forward to seeing whether this stuff is as useful to other folks as it is to us.
Having made a plug for the code I work on every day, I would like to say that every project is different, and every developer is too. You might also want to take a look at OpenInteract and AxKit. TMTOWTDI.Kwin