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

I work for a small non profit org, the guy who wrote this application no longer works for us. The app is a small intranet type system with some basic search screens. At the moment theres a index.cgi instance script and one application .pm file, then for some reason many other stand alone scripts which get called via ajax to do some things. I'm new to perl and working my way over the documents. I have to make some changes and add functionality, but first this seems un organised, each of these stand alone scripts required database config, I want to incorporate this into the .pm file so there's one configuration, and less work to do. This is not my problem. My actual problem is that when I add the functions from these scripts to my .pm file, it's huge, lots of lines of code. My question is how do I split up a CGI::Application over multiple .pm files, for example one for common things, one for ajax stuff, etc. Thanks in advance
  • Comment on Refactor CGI::Application and supporting scrits

Replies are listed 'Best First'.
Re: Refactor CGI::Application and supporting scrits
by Loops (Curate) on Apr 04, 2013 at 08:01 UTC

    You just want to split them into multiple .pm files and then include those into your application pm with the use command.

    If it's a small application it's okay to drop them all in the same directory and then perl will find them without you fiddling with the @INC paths

    # main pm file
use ajax;
hello();

    [download]
    #ajax.pm
sub hello
{
   print "hello\n";
}

    [download]

    Notice that there is no package declaration in the ajax.pm file. This means that all of the functions will be imported directly into your namespace with no fuss.

    All this will work, but may become a problem in the future if the application grows too large. It might be wise to separate things into their own namespaces, and use Exporter to only expose the necessities. You'll have to judge for yourself on that one.

[reply]
[d/l]
[select]
Re: Refactor CGI::Application and supporting scrits
by locked_user sundialsvc4 (Abbot) on Apr 04, 2013 at 15:50 UTC

    It is, unfortunately, very hard to make categorical statements about “what should be done” with a poorly-organized legacy application like this one.   (Dealing with stink-pots is a lot of what i do.)   The biggest gotcha that is going to warrant a lot of careful investigation is ... those AJAX-driven but individual scripts.   You need to figure out exactly how they are being invoked, and how they contribute output to be sent back as part of the reply stream.   Anything goes as to what you might find here, and the thing that you must hope you will not find is “namespace collisions” of any sort between them.   A traditional CGI application is a one-shot:   the designer knows that it will receive the request, then somehow gather-together the right bits of code to handle it, then handle it, then go-away.   If the requests are packaged as individual Perl scripts as you say, presumably only one of them would be loaded at a time so conflicts between them would not be an issue.   If you now seek to assemble them into one file, you could well be changing the situation in a way that your (hapless...) predecessor did not bother to consider before s/he split town, because now all of those modules will be loaded at the same time.

    I would suggest starting with a very careful inventory of the entire application, looking at each and every one of those independent files to ascertain the commonality between them ... and how they might conflict with one another if brought into one file.   You definitely need to understand how the dispatching mechanism works right now ... presumably a CGI::App “run mode” gets you as far as “ajax” and one module takes it from there ... somehow.   As you seek, then, to re-factor this thing to use a more intelligent strategy, you also must consider a way to do it in stages, not all-or-nothing.   The monstrosity somehow has to remain in-service the entire time it is being rehabilitated.

    You probably should figure out some way to set up a test-machine pointing to a test-database, and look at Selenium or a similar web-GUI testing mechanism so that you can verify automatically that the functionality of the total site is not being interrupted by any of your changes.

Re: Refactor CGI::Application and supporting scrits
by Anonymous Monk on Apr 04, 2013 at 08:13 UTC
[reply]

Back to Seekers of Perl Wisdom