Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
Perl: the Markov chain saw
 
PerlMonks  

Re: Why CGI::Application?

by jeffa (Chancellor)
on Jan 13, 2004 at 17:03 UTC ( #321036=note: print w/ replies, xml ) Need Help??


in reply to Why CGI::Application?

Maybe if you understood where C::A came from, you might understand why we use it.

In the beginning there was the very large if elsif ... else structure of blocks.

It worked, and it was good ... but not for long.

Then came the dispatch table of subroutine references:

my %dispatch = map {$_ => eval {\&$_}} qw(login logout view_list etc); my $command = $q->param('cm'); # validate $command and possibly set login as default value # now call the correct subroutine to handle this "page" $dispatch{$command}->($q); sub login { my $q = shift; ... } ...
and this was much better. But it became tedious to type the same stuff over and over again.

Then came CGI::Application which handles this and so much more. It is not easy to get the hang of, however. For what it is worth, i didn't get it the first time i tried and i could code a dispatch table solution in my sleep! :)

One last comment about one of your comments: "It seems as though all of the benefits of C::A are things that can be accomplished by simply adjusting your coding style; making more blocks of code into subroutines, etc."

Do not mistake what you have just said with being against C::A. Instead, C::A force you to abstract more than the if-elsif-else brute force solution. But, as my uncle says ... brute force is still good. It's easier to understand how to write. But, i say it turns into spaghetti eventually.

In the end, i think it's all about where you put stuff. Energy cannot be created or destroyed, and whereas code can be condensed and refactored, you still end up with code and i think the best decisions are the ones that make your code easier to maintain and easier to extend in the future. It's all about how quickly you want to solve the problem and how much the future matters to the project.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)


Comment on Re: Why CGI::Application?
Download Code
Re: Re: Why CGI::Application?
by stevecomrie (Beadle) on Jan 13, 2004 at 17:33 UTC
    In the end, i think it's all about where you put stuff. Energy cannot be created or destroyed, and whereas code can be condensed and refactored, you still end up with code and i think the best decisions are the ones that make your code easier to maintain and easier to extend in the future. It's all about how quickly you want to solve the problem and how much the future matters to the project.
    Well said, rarely on a project do you have more time then you need, and never should you be unconcerned about the future state of your code.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2014-04-20 03:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls