Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

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

by perrin (Chancellor)
on Mar 26, 2009 at 15:06 UTC ( #753431=note: print w/replies, xml ) Need Help??

in reply to Re: What is the Perl Web Framework du jour?
in thread What is the Perl Web Framework du jour?

I wouldn't say CGI::Application is a persistence framework. It's a simple tool for writing MVC apps.
  • Comment on Re^2: What is the Perl Web Framework du jour?

Replies are listed 'Best First'.
Re^3: What is the Perl Web Framework du jour?
by mr_mischief (Monsignor) on Mar 26, 2009 at 16:51 UTC
    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 article, the Perl5 Wiki entry on CGI::Application, this earlier 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.

      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.

        The modules concern is'nt that a hosting provider doesn't let you install modules. Those providers should never be even considered. It's that some hosting providers have methods for doing so, but that their methods create unpleasant overheads. Some let you install modules for the single site itself, but then you have to do bugfix updates for every site individually even though they're on the same server. Others will let you request a module to add server-wide, but they make you request each one individually or take a while to give the response. Still others let you install in one place for all your sites without interfering with other customers of theirs even without a VPS or a full server, and that's great. A VPS or full server hosting arrangement of course shouldn't pose any problems.

        The advice to keep an entire application together in one place was actually an article published by O'Reilly on several years back (2001, to be exact). It's this one, written by Jesse Erlbaum who is referenced many times on the project's web site (often by first name only). Now, I'll admit that web applications have grown on average past what was expected in 2001, and the advice makes more sense for small, simple applications than for larger, more complex ones. It's good to know you don't recognize that advice, because I'd hate to think it's still being given. It's bad enough it was given then.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://753431]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (9)
As of 2018-06-21 09:13 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (117 votes). Check out past polls.