Re: What is the Perl Web Framework du jour?

[mr_mischief]

This is just a small list. See this Perl 5 Web Frameworks Wiki and even more references at the sites listed below (often to even lesser-known frameworks) for more information. All of these should handle sessions, and I know most of them have some Ajax-y support. Those that don't can mostly be teamed with CGI::Ajax, HTML::Prototype::JS, JQuery, Google::AJAX::Library, HTML::Dojo, or other Ajax modules.

As mirod says, there's Catalyst (http://dev.catalystframework.org/wiki/), which by all accounts is a modern Web framework. It happens to follow the popular MVC model. There are also others to look at if Catalyst doesn't tickle your fancy.

There's also Jifty (http://jifty.org/view/HomePage), which I understand to be somewhat Rails-like. There's a focus on things like DRY (don't repeat yourself), form-based dispatch, and continuations.

Then there's HTML::Mason (http://masonbook.com/), which allows a bit of a PHP feel if you like that sort of thing, but with the power of Perl. It's been called mostly a template framework with some other web-aware pieces, but big web applications have been written using it. It can be used as just the templating part and even inside another framework.

I hear more and more about the Mojo web framework framework and one of the sample frameworks for it called Mojolicious (http://mojolicious.org/) as time goes by. I'm guessing that means it's gaining popularity at least with a few anecdotal groups. The website says Mojo focuses on a clean object orientated API, code generation, supporting the creation of more specific web frameworks, and the ability to run under lots of constraints. It offers its own HTTP server, runs under CGI with another server, or runs as FastCGI^*. Mojolicious is an MVC framework built on top of Mojo as a fully functional working example.

Maypole (http://maypole.perl.org/) is another MVC, this time similar to the Java framework Struts. A main focus is to give an easy path from web page to a database and back to the web page. The authors claim it is able to provide a fully featured interface to a database in under 20 lines of code your custom code, yet still be flexible enough to handle everything else a web site needs.

I don't hear much about Gantry (http://www.usegantry.org/) on PerlMonks, but it has an impressive checklist of features. It offers built-in CRUD support, explicitly supports user authentication and sessions, performs code generation, has a plugin architecture (and a number of plugins ready to go), generates and validates forms, it has a self-contained mode (including using HTML::Server::Simple to serve the application on your local machine) for rapid local development, and even that supports three different databases (PostgreSQL, MySQL, and SQLite). It runs under CGI, mod_perl, or FastCGI^*. You really need to see the 3-minute movie of the application and database generation, updates, and testing that's featured on the homepage before you make a decision about a framework. It has a little bit of a minilanguage of its own on the command line, but a simple multi-table CRUD database interface can be written entirely in one command line.

There's CGI::Application (http://cgi-app.org/), which as the name implies is meant to support applications running on the Web. It is mostly a persistence controller/dispatcher^** framework alongside which you can build your model and view^**. It has plugins so you can include extra code for extra needs, though, and the website lists many other modules that can work in conjunction with it. It even lists examples for using things like CGI::Ajax and DBIx::RecordSet with it. There are also fuller frameworks built around it or fashioned after it.

One of the frameworks derived from CGI::Application is Titanium, which is basically CGI::Application and a standard set of plugins and a bit of interface around it all. It offers lazy loading of its plugins. It runs under CGI, FastCGI^*, or mod_perl.

Combust (http://combust.develooper.com/) is an MVC web framework and CMS rolled into one, with Subversion support for documents, a caching mechanism, and automatic POD to HTML conversion and formatting. It's used at http://perl.org and it sounds handy to any Perl programmer for some of those features. I hear it has rough docs, though, including from the CGI::Application website.

There are probably a number of these (if not all of them) that can support your site development well. Some of those listed are quite popular while some are more obscure. I've tried to make a note of my understanding of the place of each in the community as well as in the scheme of features and style of use. I haven't used most of them for serious work, though, so you might want to follow up with questions to the Monastery about the ones you find interesting.

^* FastCGI is a popular cross-language standard for persistent web programs that under Apache uses mod_fastcgi. There are also FastCGI implementations for many other web server packages. FastCGI programs run separately from the web server and talk to it over sockets. Some, but not all, web hosting providers are more willing to install FastCGI than mod_perl.

^** Updated as per discussion with perrin. I'm convinced I placed the wrong focus on CGI::Application the first time around.

[perrin]

I wouldn't say CGI::Application is a persistence framework. It's a simple tool for writing MVC apps.

[mr_mischief]

Parts of this may be me repeating the misunderstandings of others. Part of it may be from reading dated material, as CGI::Application has been around much longer than some of the other frameworks and has undoubtedly had more updates and maintenance done to it. Part of it may be that I'm just focusing on the parts that seem to differentiate one framework from another a bit too much where they're otherwise similar.

The core of CGI::Application itself, without the plugins, though, really seems to me to be the state machine for the runmodes, the hooks to plugins, the wrappers to template modules you could use in any other framework or without one, and not much else. I thought that was the point. The Session, Authentication, BREAD, and DBH plugins don't even come as part of it.

More accurately than a persistence framework, it might be called a controller framework as the very core appears to be a dispatcher with a lot of hooks. A controller is certainly a good start at MVC, but it's not offering to generate the model or the view for you like some of the other frameworks do. That sort of simplicity it seems is the point. I can't imagine many applications being written with CGI::Application that don't also use some combination of CGI::Application::Plugin::Session CGI::Application::Plugin::DBH, or HTML::Template (which can be used with any framework or without a larger framework), though. Most of the others would be, by the philosophy of customizing the framework for the application espoused on the website, only used (and thus often only installed) if a site is built to use them. That's great if you have the authority to install modules as you want or you can tell your hosting company you want every plugin you may ever use for CGI::Application. It could be a real hassle, too, compared to some of the more comprehensive frameworks getting installed once.

For some idea of where I'm getting ideas about CGI::Application, take a look at these: the plugin page, Titanium, this Perl.com article, the Perl5 Wiki entry on CGI::Application, this earlier Perl.com article praising CGI::Application over Mason and other tools that use separate files for separate parts of an application, the descriptions of other web frameworks according to the CGI::Application team in comparison to their own work, and the breakdown of features and implementation vs. Catalyst (notice that CGI::Application uses plugins for most of that).

It particularly intrigues me that one of the big selling points of CGI::Application according to some of those sources is keeping all the code in one file. That's a horrible way to develop a large application IMO. There is among CGI::Application proponents some bashing of PHP, ASP, Mason, and other tools for necessarily going to the other extreme of having every function of an application in a separate file which isn't even true. I don't see why major sections of functionality can't be located separately on disk for the sake of organization, with each subsection generating more than one page out of a related set of pages for the viewer. If making the logic of the application one big collection of run modes in a single file is a selling point, I for one am not buying.

[perrin]

Your understanding is correct, but I don't know where you got "persistence framework" from. Class::DBI or Tangram or Pixie are persistence frameworks. CGI::Application doesn't persist anything. It's an MVC web framework.

I think your concern about installing modules is unfounded. Either you can install modules or you can't. No one should use a hosting provider that won't let them install modules, and with the thousands of providers to choose from there is no reason any needs to.

Regarding yur "keeping all the code in one file" complaint, that might be the attitude of someone on a mailing list, but it has nothing to do with CGI::Application itself. CGI::Application imposes no restrictions on how you organize your code. When I've used it, I just broke things up into logical applications.

[doom]

Then there's HTML::Mason (http://masonbook.com/), which allows a bit of a PHP feel if you like that sort of thing, but with the power of Perl.

Isn't it PHP that has a feel (a little) like Mason?

Mason is my personal pick, by the way. My guess is this whole ORM thing is yet another fad that's going to blow over (caveat: Object-Oriented Programming struck me the same way).