http://www.perlmonks.org?node_id=321036


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)

Replies are listed 'Best First'.
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.