Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: Why CGI::Application?

by schweini (Friar)
on Jan 18, 2004 at 02:02 UTC ( #322131=note: print w/ replies, xml ) Need Help??


in reply to Why CGI::Application?

hey! cool! finally a discussion about C::A with a lot of good arguments (mod_perl reusability, etc.)
but a lot of monks pointed out that the if/elsif constructs (that i use a lot) are inherently flawed, and i'd just like to take advantage and ask why?
assuming one doesn't use any advanced features of C::A, does one actually gain a lot by using it? is calling a sub noticably faster than letting the perl interpreter run through all the conditions? why exactly does C::A increase code mainainabilty?

to explain my situation: i bundle up anything related in seperate .pl files, which all do global start-up scripts (for session-handling, db-connections, etc.), and all 'interesting' and reusable subs are inside various modules that get used where appropiate.
i'm just wondering whether i'd gain a lot by switching to C::A (which, AFAIK, wouldn't be tooooo hard), because of the tons of positive comments about it...


Comment on Re: Why CGI::Application?
Select or Download Code
Re: Re: Why CGI::Application?
by dragonchild (Archbishop) on Jan 19, 2004 at 13:46 UTC
    A few answers. Let's say you have a reasonably complex application. Let's say you have, oh, 100 unique pages. That's right about middle-sized (in my experience). Let's say they're broken up in 4-7 different functional areas, with some overlap (searching functionality, etc), but each has different needs (different shared functions, validators, etc).

    Now, there's a number of different architectures one can do. I'm going to assume you're using templates and an RDBMS (like MySQL or Oracle). I'm also going to assume you're using intelligent developer practices, such as design, documentation, and testing.

    1. Monolithic: One script. Period.
      I hope I don't have to tell you why this is bad. Maintenance, performance ... it all suffers.
    2. Communist: One script is one unique page. They all live in the same cgi-bin directory.
      I don't know about you, but I'm going to run out of ways to name my scripts. Also, I'm going to want a way of saying "This script and that script are related" in the filename.
    3. Clannish: One script is one unique page. Each functional area has its own sub-directory.
      So, now we have a "Reports" and a "Preferences" and a "Admin" area. Each script is still named uniquely, but they're now named relative to their directory.

      (In all the "One script, One page" options, you also have the fact that you have a bunch of other files running around, attempting to link everything together. This is the shared code, from "How do I get a $dbh" to "How do I print" to "How do I log an error". This is maintained separately.)

    4. Socialist: One script is one functional area.
      Now, you're developing similarly to C::A. Except, you're doing everything C::A does for you. By hand. In multiple places. Most likely with if-elsif-else. You probably have a bunch of objects you create to do the heavy lifting. They either inherit or delegate to other objects which answer the shared code questions.
    5. CGI::Application: One script is the entry point to one functional area. C::A does the heavy lifting.
      Now, you're cooking with gas! You have one class that has your app-wide stuff. Each functional area has one class which contains the uniqueness of that area. Each page view has a run-mode, as well as each page action. You don't worry about how stuff is connected - you just play with the TinkerToys(tm).

    I would consider that an evolutionary scale. C::A does a lot of the heavy lifting for you. It also is self-documenting. In other words, you don't have to think about (and potentially mess up) some of the nitty-gritty details. To me, that's a "Good Thing"(tm).

    ------
    We are the carpenters and bricklayers of the Information Age.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (7)
As of 2014-12-25 14:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (160 votes), past polls