What's the best approach to migrate a CGI to a Framework?

Question

i have a big web application running in perl CGI. It's running ok, it's well written, but as it was done in the past, all the html are defined hardcoded in the CGI calls, so as you could imagine, it's hard to mantain, improve and etc. So now i would like to start to add some templating and integrate with a framework (catalyst or CGI::application). My question is: Somebody here has an experience like that? There is any things that i must pay attention for? I'm aware that with both frameworks i can run native CGI scripts, so it's good because i can run both (CGI native ad "frameworked" code) together without any trauma. Any tips?

Agitate

Answer 1

Write tests first (for example with Test::WWW::Mechanize). Then when you change things you always know if something breaks, and what it is that breaks.

Then extract HTML into templates, and commonly used subs into modules. After that it's a piece of cake to switch to a framework.

In general, go step by step so that you always have a working application.

Zloty

Answer 2

Extricate the HTML from the processing logic in the CGI script. Identify all code that affects the HTML output, as these are candidates for becoming template variables. Separate that into a HTML file, with the identified parts marked with template variables. Eventually you will be able to refactor the page such that all processing is done at the start of the code and the HTML template just called up at the end of all processing.

Edmondson

Answer 3

In this kind of situation, rewriting from scratch basically, the old code is useful for A) testing, and B) design details. Ideally you'd make a set of tests, for all the basic functionality that you want to replicate, or at least tests that parse the final result pages so you can see the new code is returning the same information for the same inputs.

Design details within the code might be useless, depending on how much the framework handles automatically. If you have a good set of tests, and a straightforward conversion works well, you're done. If the behavior of the new doesn't match the old, you probably need to dig deeper into the "why?" and that'll probably be something odd looking, that doesn't make sense at first glance.

One thing to remember to do first is, find out if anyone has made something similar in the framework you're using. You could save yourself a LOT of time and money.

Deannedeans

Rewrite from the scratch is not an option for a system with more than 5k lines. But anyway, thanks for your inputs! – Agitate

Answer 4

Here is how I did it using Python instead of Perl, but that should not matter:

1. Separated out HTML and code into distinct files. I used a template engine for that.
2. Created functions from the code which rendered a template with a set of parameters.
3. Organized the functions (which I termed views, inspired by Django) in a sensible way. (Admin views, User views, etc.) The views all follow the same calling convention!
4. Refactored out the database and request stuff so that the views would only contain view specific code (read: Handling GET, POST requests, etc. but nothing low-level!). Relied heavily on existing libraries for that.

I am here at the moment. :-) The next obvious step is of course:

• Write a dispatcher which maps URLs to your views. This will also lead to nicer URLs and nicer 404- and error handling of course.

Cull

Answer 5

One of the assumptions that frameworks make is that the urls map to the code. For example in a framework you'll often see the following:

http://app.com/docs/list
http://app.com/docs/view/123

Usually though the old CGI scripts don't work like that, you're more likely to have something like:

http://app.com/docs.cgi?action=view&id=123

To take advantage of the framework you may well need to change all the urls. Whether you can do this, and how you keep old links working, may well form a large part of your decision.

Also frameworks provide support for some sort of ORM (object relational mapper) which abstracts the database calls and lets you only deal with objects. For Catalyst this is usually DBIx::Class. You should evaluate what the cost of switching to this will be.

You'll probably find that you want to do a complete rewrite, with the old code as a reference platform. This may be much less work than you expect. However start with a few toy sites to get a feel for whichever framework/orm/template you decide to go with.

Mormon