I have used and researched many different web frameworks over my years as a web app developer. I have found that the general "try to do everything" frameworks are often not very good, because they try to be too general.

Some examples are Enterprise Java Beans (sorry to not use a Perl example, that is coming shortly). They try to do everying, but because they are so flexible, the developer ends up doing way too much extra work.

Then there are frameworks that focus on a particular type of application. For example, java struts work well for designing strut-stype applications. EZ publish (a PHP kit) works well for news sites.

So, what is happening is that it is very difficult to make something that works for all jobs. The more specific your target, the better job you can do designing a solution. This is true for app frameworks.

For that reason, I like to plug together a set of different tools to meet my needs on a per-job basis. For example, in one application, I might use Class:DBI as my database interface and Template Toolkit as my view generator. But another job might be easier to develop if I used DBI as the database interface.

Now, moving more specifically to your example: how do you validate a form, or an email? How do you manage a session? It changes from one category of application to another.

While it may take a little extra work glueing your components (APIs) together, the trade-off in flexibility is worth it (for the kinds of apps I deal with).

In short, it is very hard to put something monolithic together that will serve many jobs. Of course, by my very own assertions, it is quite possible that you can put together a framework that meets the needs of the types of apps you develop very well.

I really *hate* choosing all that stuff. I use CGI.pm, Class::DBI and Template because it seems these are the consensus favorites (I have zero statistical evidence).

One of *my* favorite things about Perl is the massive number of modules on CPAN. This is why I try and pick the most popular Web app components -- they are more likely to have cool plugins/extensions/subclasses of their own.

I have checked out Catalyst but, for my tastes, it has too many options, allowing me to choose which templating system, object-database mapper, etc, which feels to me an awful lot like "back to square one." This profliferation of options is probably why I can't get my head around the Catalyst documentation. Everything is much more complicated than it needs to be because TMTOWTDI.

I would be thrilled if someone made some smart decisions and put together an intelligently documented Web framework. I want an opinionated "super CGI.pm." What a great way to put it. ++dhoss.

Don't get me wrong -- I love that the options exist on glorious CPAN, and I respect why people prefer a custom-rolled solution or a looser framework. I just want the option of ... less options ;->

This sounds a lot like Rails in the Ruby world, but Rails boots its own webserver and has all kinds of code generation. It would be cool to start something that runs acceptably under CGI and then if you want it faster/more custom you just move it to an established, scalable persistence system like mod_perl or fastCGI (thus avoiding some of Rails' scalability pains).

If CGI::Application doesn't feel like the right tool, dhoss, you might check out CGI::Prototype by Randal Schwartz, which is a very cool control layer, albeit one with all sorts of Smalltalk-like hairs growing out of it. You might hate those hairs, or decide they are extremeley neat and Perl-ish in the best sense of the word. Adding methods on the fly would be an extremely useful way to extend a Web framework, and a Prototyped class gets you there.

Some sort of mix of that, Class::DBI, Class::DBI::Loader, Template (aka Template Toolkit) and a form module like CGI::FormBuilder could be a great "super CGI" with the right amount of glue code and a light touch.

And a text search module like Kinosearch could be a great foundation for a first plugin.

Of course the exact mix of modules is rather inconsequential to me. I'll gladly trade DBIx::Class for CDBI or Data::FormValidator for CGI::FormBuilder or HTML::Template for Template if the framework is smooth enough.

I really like how you worded this post. These are basically my exact sentiments.

I'm not sure i want something as big as Catalyst, but maybe i'm wrong. I'll definitely look into trying it out, and maybe i can hack something out and add it on, and perhaps, submit it as a patch.

meh.

I don't like having


use Foo;
use Bar;
use Baz;
use Quux;
use Foo::Bar;
...
[download]


I'd much rather have


use Super::Foo;
my $super_cgi = Super::Foo->new;

...
[download]

meh.

In that case, consider writing your own meta CGI::Application module:

package Dhoss::App;

use Foo;
use Bar;
use Baz;
use Quux;
use Foo::Bar;

use base 'CGI::Application';

1;
[download]

Then start out every app based on that super class (use base 'Dhoss::App';). Easy peasy.