Cody Fendant has asked for the
wisdom of the Perl Monks concerning the following question:
I have a perl/MySQL website which is running well and suiting the client needs, but I'd be the first to admit, it's a bit rough. I'd be a bit embarrassed if one of you monks had to take it over from me, put it that way.
How it works is:
- If a URL on the site exists as a static file, it's served as normal.
- If not, Apache redirects to a single perl script.
- That script splits the path and acts accordingly,
- say the path is /chicago/south/drycleaners/j-smith-and-sons, that's the path to a specific business, so $mode = 'business' and the if($mode eq 'business'){ ... } block is invoked,
- but if it's just /chicago/south/drycleaners/ that's a list of all businesses in a certain category so the if($mode eq 'category'){ ... } block runs, and so on.
Things I need to fix:
- This single perl script is getting large and complex, so I should probably think about putting the different code sections into modules.
- It would be better to use a framework, though not a very complicated one -- would Catalyst be overkill for something like this? Maybe CGI::App? Maybe just moving those big blocks into MyApp::BusinessMode and MyApp::CategoryMode modules would be enough?
- More flexibility for the future when the client has new ideas.
- Like I said above, just generally more professionally organised code so that whoever works with it in future, including me, it's more logical and modular.
By the way, there's only reading from the database and HTML display involved. No updates or inserts, no authentication/personalisation, just pulling data, putting it into HTML::Template and output to the browser.
Any suggestions very gratefully received.
Re: I want to professionalise my quick-and-dirty web app by GrandFather (Cardinal) on Apr 24, 2012 at 06:43 UTC |
From your description so far it's not clear how categories map to the database. With a good mapping the code to resolve a path to a database row or set of rows should be fairly compact. Perhaps you could show us a small sample of the parsing and rendering code and tell us a little about how the database is structured?
True laziness is hard work
| [reply] |
Re: I want to professionalise my quick-and-dirty web app by Anonymous Monk on Apr 24, 2012 at 07:33 UTC |
Like grandfather says, generate some representative sample data (mock data), then write a test suite around the mock data, and put it into version control
Once you have mock data and test suite, its time to refactor, more on this in What is the best way to add tests to existing code?, Re: Idiomize This - Cleanup/Transform, Re: Moose and Antlers!, Re: Splitting a project into smaller files, Re^3: A question about web service security, Re: What CPAN Modules are Good to Learn From?, Developing a module, how do you do it ?
The actual framework you choose ( Catalyst or Badger Power ... ) is not that important, what is important is making functions , documenting what they do, making sure they work as documented, making sure the program (the public interface ) works the same -- basics of maintainability
| [reply] |
Re: I want to professionalise my quick-and-dirty web app by scorpio17 (Prior) on Apr 24, 2012 at 13:16 UTC |
| [reply] |
Re: I want to professionalise my quick-and-dirty web app by sundialsvc4 (Monsignor) on Apr 24, 2012 at 13:22 UTC |
CGI::Application is a venerable piece of code that has had many followers ... too many to list here. If you search for that module-name you’ll find some of those followers, paying homage to it. The core responsibilities of parsing a URL-string, identifying a handler, possibly loading that handler and executing it are available in many routines ... Mojolicious, for example.
My suggestion would simply be that you consider several of them: without changing anything about your code, consider what the changes might be. With a number-two pencil and a piece of paper, and with a wastebin nearby, start making sketches and to-do lists.
When you do get ready to make changes, then it’s definitely time to first put the whole thing under version-control, e.g. with git. (I suggest git because it requires virtually no setup and no server; of course, it’s free, and if it’s good enough for managing the Linux Kernel it’s good enough for you.) You can introduce the code, make one “branch” from that which represents “what you’ve got now,” then from the same root-point make other “branches” which represent your various experimentations. You can safely and reliably now switch between them at-will. You can, if you will, “now afford to completely screw-up” :-) because, well, merely checkout another branch and (presto!) you didn’t screw-up at all. You can take the code from that or any other starting-point (one branch), make explorations in a new branch or branches, and always be able to reliably get back to precisely that starting-point.
| [reply] |
|
|