I suggest you look at CGI::Application. It sounds like it will do exactly what you're looking for, and helps you create very manageable, usable apps without getting in the way. I love it! I use it extensively in apps that work similarly to what you're describing, and I can't imagine building web applications without it and HTML::Template.

You might also check out OpenInteract by lachoy, it appears to be a very robust application framework with a good security model.

-Any sufficiently advanced technology is
indistinguishable from doubletalk.

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.

I have had a great deal of success building web apps by subclassing CGI::Application (which uses HTML::Template). It is especially useful since it provides a single jumping off point for all of your applications level code.

I would not attempt building any application more complex than a single form without it.

dmm

CGI/Mod Perl Application Design philosophy - which way do we go? is a pretty good thread about this kind of thing. I'd normally recommend OpenInteract (as some other kind folks have mentioned), but it does not currently run under a CGI environment, just mod_perl. CGI/standalone/POE/... is in the future, but not yet.

I don't think anyone else has mentioned it yet, but OpenFrame is pretty nifty and IIRC runs under CGI no problem.

Chris
M-x auto-bs-mode

My preferred method is to create a sub-class of CGI::Application that includes anything site-wide I want to use. My application modules are then subclasses of this class. (It makes more sense when you read the CGI::App docs)

It's exactly what you describe -> it takes Perl OO to another level, and has a lot of well-thought-out abstractions for security and persistence.

I've implemented a very small site in it and learned a lot.