Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??
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.


In reply to Re^3: What is the Perl Web Framework du jour? by mr_mischief
in thread What is the Perl Web Framework du jour? by crenz

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-03-28 21:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found