Re^3: What is the Perl Web Framework du jour?

[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.