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

Hi Monks,

It's three and a half hours away before 2004 for me. Ah...let me make a last post before bidding farewell to the year of Ram.

First things first, a very HAPPY NEW YEAR to all of you!

Here we go...

I'm thinking along the line of a default html file index.pl (exactly like the perlmonks' index.pl). I'm not sure if it's a good idea to make a do-all script for all the site's functions including membership registration, logging in/out, managing the members' database, simple forum, etc. It's not a self-contained script i.e. index.pl is tied to a number of modules that store certain shared subroutines.

The other option is to have separate scripts performing the different functions. For example, register.pl for membership registration, login.pl for logging, forum.pl for managing the forum etc.

Which of the two options is a better one? I was thinking about load on the single script as well as code maintenance but I guess there're other issues.

I look forward to hearing from you.

Thanks in anticipation :)

  • Comment on All-in-one script vs independent scripts

Replies are listed 'Best First'.
(z) Re: All-in-one script vs independent scripts
by zigdon (Deacon) on Dec 31, 2003 at 13:59 UTC

    I was pondering this same thing 5 years ago. Don't make the mistake I made - I went with the all-in-one script. Bad idea. Now I'm stuck with a script that's about 5000 lines long, and perl needs to read and compile all of those lines for every single request to the server. This is not as big of a deal if you're running under mod_perl, but in a CGI environment, bad, bad idea.

    Make your scripts do one thing, and do them well. I'm just starting to get into working with HTML::Mason (which rocks!), and I'm starting to learn that it's even a good idea to seperate the script that displays the form from the script the processes the results!

    So my advice (which you did ask for! :), is to make your scripts small, focused and therefor easy to maintain. The end user doesn't need to know it's not all under one über script - the details can be hidden with redirects.

    Hope that helps!

    -- zigdon

[reply]
Re: All-in-one script vs independent scripts
by jdtoronto (Prior) on Dec 31, 2003 at 17:35 UTC
    I have one worse than Zigdon - a few years back we purchased a script wich was about 6,000 lines - all in one file, it grew to over 35,000 lines. It became an absolute dog. So we tried running it under mod_perl and ran into the Global Variable nightmare. For version 4.0 and up we split it into one script per function with a common subroutine library. Much better. But we ended up with about 40 files, all with 'heredoc' type HTML output and often the same thing being implemented different ways.

    It is being re-written for v6.0 now. At the moment we also have a new web-app in hand. So we are doing both of these jobs using CGI::Application, HTML::Template, Data::FormValidate, CGI::Application::ValidateRM and CGI::Session as the basis of our framework. We have wrapped CGI::A so as to provide us with common methods for validation and session management. A separate module provides a wrapper around Class::DBI to provide SOME of our DB access, even Class::DBI and all its friends cannot give us all we need so we have another module that provides a variety of methods to handle other DB access which we may port to Class::DBI as we develop more internal skills.

    Now we have the best code re-use we have ever had. All our modules and their various methods are far better documented than ever before and we are outputting code at about three times the rate we experienced in the past. v5.11.0 of the monster was still classic CGI style app running under mod_perl, it had 87,510 lines of code. A feature enhanced CGI::A version with approximately 350 HTML tempaltes, 125 run_modes and all our helper modules totals 12,500 lines of Perl (add tempaltes to that of course for total job size) and we have an app that we can dynamically skin for appearance and already maintenance is proving to be a dream - at least during the debugging phase.

    My story? Years of bitter experience teaches me I should have learned OO Perl years ago! Modules and Packages are the way to go! Break it up into little bits, debug and test well, then reuse them wherever you can!

    jdtoronto

[reply]
Re: All-in-one script vs independent scripts
by Art_XIV (Hermit) on Dec 31, 2003 at 14:18 UTC

    IMO, creating a nice set of modules/classes is almost always better than a monolithic script in terms of maintainability once your project gets beyond a couple hundred lines. A well-thought-out set of packages (and a nice set of tests!) will tend to be much easier to change/tune/update as time goes by, and you might even get some good re-use out of your code.

    There typically is a very minor performance penalty for modularizing your code like this, but the maintainability payoff is generally more than worth it.

    Hanlon's Razor - "Never attribute to malice that which can be adequately explained by stupidity"
[reply]
Re: All-in-one script vs independent scripts
by arden (Curate) on Dec 31, 2003 at 17:06 UTC
    From my experience, it is much, much easier to maintain several different scripts than a single monster. It's easier to identify what each is doing, you don't have to worry about reusing a variable by accident or a missing bit of punctuation screwing up a different section of code.

    If you really want it to appear to users that you're using one script, have an up-front script that uses the first argument returned to determine which other script to exec on the server, then passes all the remaining arguments on to the new script. From the user's perspective, they are always using index.pl, but on the server, you're calling different scripts for different tasks...

[reply]
Re: All-in-one script vs independent scripts
by xenchu (Friar) on Dec 31, 2003 at 17:29 UTC

    You have already heard from better Perl programmers than I, but I do have a good deal of experience with programming in other languages.

    My advice is what they said. In any programming language, in my experience, the more lines of code in a program the harder it is to debug and maintain. Besides exhaustive testing, rigid standardization of variables, file names, etc. is somewhat helpful. And standardization of variables and file names helps with maintaining close-coupled programs as well. Do the small, individual programs that do one job well. You won't be sorry.

    HTH

    xenchu

    The Needs of the World and my Talents run parallel to infinity.
[reply]
[d/l]
Year of the Ram/Monkey
by Mr. Muskrat (Canon) on Dec 31, 2003 at 23:24 UTC

    Ah...let me make a last post before bidding farewell to the year of Ram.

    You are not going to post anything else before January 22nd? ;-)

    Just so that you know, the last day of the Year of the Ram (4700) will be January 21, 2004. The first day in the Year of the Monkey (4701) will be January 22, 2004.

[reply]

      Happy (Chinese) New Year!

[reply]

Back to Seekers of Perl Wisdom