debiandude has asked for the wisdom of the Perl Monks concerning the following question:

Hello everyone

I posted a question two days about about CGI::Application. You can find it here. In the node I was asking how to break up a CGI::Application into more than one modules.

After I got that all sorted out I started modifying my code to the suggestions listed in the page. However, I started noticing after I broke up my C::A into a Superclass and a bunch of modules that I really didn't need to have more than one runmode to a modules. That is each runmode had no shared code (there was a few excpetions, but for the majority this was the case).

So is it a good/bad pratice to have each runmode a seperate module (i.e. each runmode is then accesss by going to: http://site.com/runmode.pl instead of http://site.pl?module?node=runmode.

What's your opinion? Is making a module for each runmode overkill?

Replies are listed 'Best First'.
Re: Preferred Method with CGI::Application
by dragonchild (Archbishop) on Jun 02, 2006 at 22:14 UTC
    You're doing too much per runmode. Break up your processing into multiple runmodes. For instance, you should have a "display_values" runmode and a "proces_inputs" runmode that redirects (using CGI::Application::Plugin::Redirect) back to the "display_values" runmode. (This prevents the Refresh-resubmitting problem.)

    If you analyze it from a state machine POV (which is what C::A is), you'll find the number of runmodes increasing and the amount of code per runmode decreasing. Generally, I have between 4 and 8 runmodes per child class with 12 being a ceiling that should be breached only if everyone on the team agrees. I've had 2 before, but never less.

    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?
[reply]

Back to Seekers of Perl Wisdom