views:

70

answers:

2

I have a general question about Perl CGI programs. For a few applications, not using MVCs, developers write CGI programs, may be using CGI.pm or some other way they like and for moving from screen to sceen, a new CGI program is written, (with - CVS TAGS, Perl headers etc etc..).

But what I feel is if there is some stuff (subroutine or business logic) which is not required in other programs, I keep on calling same script with each page called based on one extra Role parameter. Benefit I get is one time header declaration, easy to maintain,

%frmData = CGI::Lite->parse_form_data();
$Role    = $frmData{Role};
if ($Role eq 'A'){ getPageFirst()}
elsif ($Role eq 'B'){ getPageB()}  etc..

Is this a correct approach? Can we face some kind of problem. What will be the best approach?

+2  A: 

I think combining a bunch of functionality (several CGI) into one file does not really help maintainability.

The alternate approach would be to keep the CGI apart and put the common code into separate files (such as Perl modules), that each of them can include.

You mention you are worried about including too much stuff that is not necessary for all of the CGI. It seems to me that with the combined big CGI, you are actually making this situation worse. With modules, you can include what you need.

Can we face some kind of problem?

The first problem you will likely face with CGI is performance, because the script needs to be reloaded all the time. So you want to look at something like FastCGI, which keeps the script (and libraries) in memory between requests. If you go there, having your code base properly divided into modules will help.

Thilo
Forget to mention, I am already keeping common things in modules, and basically I am calling functions from modules based on Role. But I will take a look at Fast CGI too..
awake416
If your CGI just ends up dispatching to other code based on Roles, that sounds about right. That is what all the "newer" frameworks also do: have a single entry-point (CGI/Servlet/Apache Handler) and dispatch internally to other code depending on configurable rules.
Thilo
+1  A: 

Based only on what you've said, I'd say you are creating a maintenance nightmare of duplicating the same code into multiple programs and going through the same logic in every program. You probably, at least, want to move that into a shared library.

It sounds like you might have the problem that CGI::Prototype was meant to solve. It handles the selecting the page that you should be on and lets you dispatch to the right handler for it. It's a minimal framework that doesn't provide much more than that.

Without knowing more about what you are doing, it's hard to give any better answer.

brian d foy
OK. Here is it. When we do not have any kind of frame work used, and we have to implement some kind of a wizard where in four five pages may be used(and each page corresponds to one cgi.pl). There we have a few things duplicated like headers etc and when any one of the script needs to be changed, we have to make sure no one else is using it. Then if we use only one cgi.pl with each form passing values to same cgi.pl in form action attribute and call individual functions (may be from same script or from common module) instead of calling separate scripts. can we have some kind of problem there?
awake416
In Other words, I am talking about "single entry-point" as mentioned by Thilo
awake416