Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^2: CGI::Application - why?

by gunzip (Monk)
on May 15, 2006 at 02:43 UTC ( #549376=note: print w/ replies, xml ) Need Help??


in reply to Re: CGI::Application - why?
in thread CGI::Application - why?

I wanted to be able to factor my web applications into many moudules, not one which is just as big as the original CGI script. The CGI::Application examples seem to focus on getting everything into one big module so where's the modularity? I'd like to have my runmodes in distinct modules, not simply subs within one monolithic module/script.


Comment on Re^2: CGI::Application - why?
Re^3: CGI::Application - why?
by friedo (Prior) on May 15, 2006 at 03:57 UTC
    So then do that. CGI::Application does not prevent it.
      Nor does if ... elsif ... elsif ... elsif ... else. So I still fail to see the point.
Re^3: CGI::Application - why?
by dragonchild (Archbishop) on May 15, 2006 at 13:00 UTC
    Did you read the nodes in my reply to your original post? In them, I discuss breaking a large CGI application into related sub-applications.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re^3: CGI::Application - why?
by perrin (Chancellor) on May 15, 2006 at 16:56 UTC
    CGI::Application is intended to help you map HTTP requests to method calls. You can use that however you like. A common approach is to make a set of related actions into one application, and then factor out all the common code into separate modules, reducing the actual runmode code as much as possible.

    If you prefer, you can make every single action call a different module, but that would probably be massive overkill, especially since one runmode frequently calls another (e.g. if there are input errors you call the mode to show the form again, passing the errors along).

Re^3: CGI::Application - why?
by santonegro (Scribe) on May 15, 2006 at 20:31 UTC
    I found that CGI::Prototype did a good job of raising the abstraction that CGI::Application started towards. When you develop a web app under CGIP, you dispatch to modules not subroutines. And the dispatch mechanism is more general: it can be based on anything that you want: GET versus POST, any particular parameter, etc.
Re^3: CGI::Application - why?
by jdtoronto (Prior) on May 16, 2006 at 03:44 UTC
    Well, that's just what many CGI::Application users do.

    Since I started using CGI::Application a little over two years ago I find that I can get massive code re-use. Using things like Class::DBI and the many CGI::Application plug-ins now available I find that I can produce a complete web application in as little as 50 or 60 lines of code. Plus the HTML templates of course. By combining HTML::Template (I know, everybody tells me to use Template::Toolkit, but I am comfortable with HTML::Template), the session management and authenticaion plug-ins, CSS and a collection of common support modules, I have been known to produce complete 10 form applications inside a day.

    Maintenance time is drastically reduced as well. By factoring out all the common code into another set of modules, and having the runmodes as small as possible I find that a 20,000 line CGI::Application based product is vastly easier to maintain than its 20,000 line conventional CGI predecessor which I still maintain for one client.

    jdtoronto

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://549376]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (10)
As of 2014-09-19 20:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (145 votes), past polls