The traditional answer would probably be CGI and (m)any of its derived modules (to manage sessions, authentication and authorization, ...), DBI and your choice of Templating System (Template::Toolkit springs to mind).

A more modern answer would be Catalyst and any related modules in that namespace to handle your particular challenge. Again a templating system (see above) and DBIx::Class if you need a database.

And I am probably forgetting a thousand other modules you cannot do without as my brethren will certainly point out!

Catalyst looks very interesting. I've heard of it before but dismissed it fairly quickly (I didn't know much Perl at the time) DBIx is in. Now just to pick a template system..Template Toolkit seems to be popular. Do you have anything against HTML::Template for simple applications?

Templating systems are like religions, so the answer strongly depends on who you ask, or who replies... ;)

It's probably a good idea to try a few yourself to see which approach you like best.  This classic article might serve as a good introduction.

I have nothing against HTML::Template and I'm quite sure that it can handle much more than simple applications.

Template::Toolkit on the other hand is a more general templating solution which will equally well handle non-HTML / non-Web matters.

I use it regularly to write LaTex files which when rendered make nice lay-outed PDF-files. Although not impossible to do, it would require more effort to do so from a less performant templating system.

Its biggest strength is the way it can handle easily and elegantly, all kinds of data-structures (such as hashes of arrays of hashes of hashes of ...) and can use most of the standard Perl-modules (CGI, DBI, ...) directly from within itself. And before someone complains and starts a holy flame war: this indeed breaks the holy law of division of concerns and allows you to sneak in programming into your display layer, but sometimes it is damn handy to do so ...

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Just curious: why Rose::DB::Object over DBIx::Class?

No offense to DBIx::Class, I just think RDBO is great. It has excellent docs, a great feature set, and the design seems very natural to me. The support on the mailing list is friendly and helpful, and a lot of people whose technical opinions I respect (merlyn, Ask Hansen, Bill Moseley) are on there and contributing.

So, yes, just add DBI to CGI and HTML::Template, and you've got all the basics in place.

I've built fairly large and complex websites with just those three elements.

Of course it wouldn't be a bad idea to use Catalyst or CGI::Application, but the P of Least R is just to add one more module to your kit and get to work. You can always add those frameworks later, and you'll understand what they're doing better when you do.

Short of an actual CGI::Ninjutsu::Foo collection I have to recommend CGI::Application. I was sold after reading the tutorial at http://www.perl.com/pub/a/2006/10/19/cgi_application.html and it has a lot of nice plugins.

Jifty is another cool web application framework available on CPAN; e.g. Hiveminder is built on Jifty.

If you are looking for simplicity and flexibility, HTML::Mason could be a very very good choice. It works well with both mod_perl and FastCGI.

Highly recommend jQuery as the Javascript frontend library which is Perlish and really as flexible as our Perl code. :-)

Good luck

lihao

I tend to handle nearly everything else I do with the workhorses: CGI and DBI. I snatched two subroutines from Rose::DB::Object for a project two years ago (so I could handle postgresql's store an array in a single field feature), but have otherwise been happy with the old standbys. I'm fascinated by what is said above about Template::Toolkit and keep putting off reading its tutorial (which lost a recent competitive bid to the much shorter one for HTML::Template). Five years ago I wrote a 1,000 line script, significant subroutines of which hand rolled LaTeX markup for producing press releases. I keep wanting to refactor that as a module and guess TT will need to be a part of that.

What I haven't heard mentioned here yet is anything about managing configurations. My first major application used a hand rolled mess (which I'm still occasionally pulled back into maintaining). When I moved from spending less time organizing and more time coding, I found and fell in love with Config::Simple and have used it for everything since, and only a few weeks ago extended it with Config::Simple::Inherit for my current project. My hand rolled mess handles heredocs for feeding configurable copy into a webpage. But I'd love a more elegant solution and will likely refactor the heredoc handling code from that (not that many lines, really) as another extension as Config::Simple::Heredoc one of these days, unless someone else beats me to it, first.

I had a frustrating experience with CGI::Application, related to discovering conflicts where it did not seem to play well with some other module I was using on that project, but otherwise was very much impressed with its design and organization. I still write my code to return, not print my html and to organize my dispatch as CGI::App taught me, figuring that one day a future refactor might actually try to integrate it into most any project I've written since. But I still have not done more than test it since then.

Not sure that my experience would qualify me as a Ninja, or a Monk, but over the last three or four years I've felt more comfortable reliably producing working applications with the tools I have beguin to master.

-- Hugh