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] |
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.
| |
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] |
| [reply] |