in reply to Yet another "why CGI-Application" question

I would say leave CGI::Application alone until you improve your understanding of OO programming. What tutorials have you tried?

Have you looked at

Obviously, don't just read. Write code and experiment, that's the best way to learn. OOP isn't that hard, and is well worth learning.

Update: BTW, the approach you are already using is very sensible. Here is one way to break out the run-modes (untested): 

use strict;
use CGI; # or CGI::Simple

my %dispatch = (
  runmode1 => 'My::Package1',
  runmode2 => 'My::Package2',
  runmode3 => 'My::Package3',
);

my $rm = $q->param('rm');
eval "require $dispatch{$rm}" or die "runmode handler not found";
$dispatch{$rm}->handler($q);

[download]
In each package create a sub called handler that looks like: 
sub handler
{
    shift; # ignore 1st arg (package name)
    my $q = shift;
    ...
    # do what ever runmode requires
    # return html output
}

[download]

May the force be with you :)

Replies are listed 'Best First'.
Re^2: Yet another "why CGI-Application" question
by punkish (Priest) on Nov 28, 2004 at 17:26 UTC
    I would say leave CGI::Application alone until you improve your understanding of OO programming.
    I was fearing that answer ;-).

    I have read through perlboot, perltoot, LPORM, the relevant chapter in "Advanced Perl Programming' (which, of all the tutorials, I found to be the most helpful, followed by), the tutorial right here on PM. I understand OO to a degree, but then, I fail to understand how it would benefit me in my own application. And, because of a lack of time, I end up doing things my own way instead of taking time to learn something new. (the same thing happens whenever I sit down to learn Python -- after ten minutes or so I fail to see the point of learning something that will help me do what I can already do using Perl).

    Something tells me that at some point I will have to learn OOP enough to actually think that way. Until then, I want to get with creating something with what I know, unless I hit an otherwise unsurmountable wall that can only be climbed with the help of OOP. (tilly's The world is not object oriented was enlightening). Until then, something tells me that OOP is worth it only for really, really large and complicated applications. I haven't encountered that largeness yet.

    Update: I do intend to learn OOP, but I want to do that via Obj-C (I bought "Cocoa Programming for Mac OS X"). In time...

[reply]
      Well if you haven't yet read Damian's book, I strongly recommend that you do. IMO it is the best guide to OOP in Perl out there.
[reply]
        While certainly interesting, Damian's book is more of a collection of tricks than an introduction to OO programming. The introduction in Advanced Perl Programming is better, IMO.
[reply]
      Please do not use my post as an excuse to avoid OO.

      I can safely criticize OO's limitations because I understand it and know to use it where it makes sense. That it has limitations does not bother me - every tool in my toolbox has limitations. As long as I understand the limitations, I can prepare for them and avoid unexpected encounters of the painful kind.

      For the record, I've written 200 line programs in which OO was worthwhile and 5000 line programs in which it was not. OO is not just for really, really large and complicated applications. OO is for any case where its brand of information hiding and abstraction works in your favour. Based on experience, I strongly suspect that you have encountered plenty of cases where OO would have been worthwhile. However without knowing what that tool could do for you, you blithely accepted the problems from not using it because you didn't realize that those problems were avoidable.

      I'd be more specific but I can't be since I lack the specifics of your circumstances. This is why it is important to learn the technique and conciously try to apply it. After you try, seek feedback, think about how it worked, and refine your approach.

      Remember the saying, There is a difference between 5 years of experience and 1 year of experience, repeated 5 times. If you're always using the same approach because it is what you know and you think that you don't have time to try anything else, then you're repeating your first year of experience. Furthermore you are shortchanging yourself on time - consistently taking the effort to expose yourself to new approaches saves you time.

      Don't believe me? Research has consistently documented 100-fold differences in productivity between programmers. Research on the top programmers demonstrates that they spend less time coding, and more time on design, analyzing what they did, learning about new things, etc. If you're always launching directly into coding because it is obvious to you how to proceed, then you're guaranteeing that you're on the 1 end of that productivity scale rather than the 100 end.

      Now some of that difference is ability - you are unlikely to personally be able to become 100 times more productive. But some of it is not. How much of your time is it worth if you could potentially double your productivity? No, I'm not saying that learning OO will double your productivity, on some kinds of projects it will do more than that, on some it is useless. However the attitude that leads you to try it out, when applied consistently to different things, certainly can achieve that doubling over time. And probably over less time than you'd suspect.

[reply]

In Section Seekers of Perl Wisdom