Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Why CGI::Application?

by rob_au (Abbot)
on Jan 13, 2004 at 12:00 UTC ( [id://320936]=note: print w/replies, xml ) Need Help??


in reply to Why CGI::Application?

From the review which I wrote for CGI::Application on this site here ...

Why use CGI::Application?

The CGI::Application module implements this object-orientated framework within which to build your application by creating a super-class within which specific 'run-modes' can be defined. Each run-mode can be correlated to a particular stage of the HTML/CGI user interface. Furthermore, the CGI::Application module implements methods to address the CGI.pm and HTML::Template modules, facilitating powerful methods by which to build extensible and portable web applications - It is obvious that the module author, Jesse Erlbaum (jesse at vm dot com), has put a lot of work into the development and writing of this module.

This module allows you to do away with ugly code through the combination of CGI.pm, HTML::Template and methods provided by CGI::Application to implement persistent variables across execution states.

Additionally, and most importantly, by providing a framework in which CGI parameter parsing, template handling and session storage can be seamlessly incorporated, CGI::Application allows developers to focus on business logic rather than framework implementation details.

 

perl -le "print unpack'N', pack'B32', '00000000000000000000001010101010'"

Replies are listed 'Best First'.
Why CGI::Application?
by kropotkin (Initiate) on Jan 31, 2009 at 18:13 UTC
    The web page for C:A tells us that it is better than Mason because Mason creates lots of files.

    The author of that text hasn't used Mason very much. If you wanted with Mason you could put all your components in one file using the inline component block - or you could just use one component and wite a great big MVC framework if you wanted to.

    I agree 100% with the author of the original comment. The problem with a lightweight MVC framework like C:A is: a) It often adds an extra layer (to be learned and more code to load) for very little obvious benefit. E.g. to use JSON there is a JSON plugin, but this is not much more than a wrapper around the JSON module. In as much as it is more it provides a mechanism for intercepting the output in your C:A application with a hook. My problem with this is if I wanted this kind of functionality I'd rather code it myself than learn how someone else has done it.

    b) Because it is lightweight your application will end up as a hybrid beteen C:A and your own systems e.g. I've had to develop a little component system because it doesn't really do components, being stuck in this Web 1 way of thinking where the whole page is served each time. But this is messy. There are two ways out of this: either use a framework which really does cover everything, like PHP's Symfony (if that's your bag), or don't use a framework at all.

    The MVC model is fine if appropriate: but most developers should have the discipline to separate out model view and controller without being put into a strait-jacket.

    Justin
[reply]

In Section Seekers of Perl Wisdom

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?

www.com | www.net | www.org
Node Status?
node history
Node Type: note [id://320936]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? • Last hour • Other CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2024-04-16 09:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found