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.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||