Question

On my current project, we’ve been using Struts 1 for the last few years, and … ahem … Struts is showing its age. We’re slowly migrating our front-end code to an Ajax client that consumes XML from the servers. I’m wondering if any of you have migrated a legacy Struts application to a different framework, and what challenges you faced in doing so.

Answer 1

Sure. Moving from Struts to an AJAX framework is a very liberating experience. (Though we used JSON rather than XML. Much easier to parse.) However, you need to be aware that it’s effectively a full rewrite of your application.

Instead of the classic Database/JSP/Actions scheme for MVC, you’ll find yourself moving to a Servlet/Javascript scheme whereby the model is represented by HTTP GET requests, actions are represented by POST/PUT/DELETE requests, and the view is rendered on the fly by the web browser. This leads to interesting challenges in each area:

Server Side – On the server side you will need to develop a standard for exposing data to the client. The simplest and easiest method is to adopt a REST methodology that best matches your data’s hierarchy. This is fairly simple to implement with servlets, but Sun also has developed a Java 1.6 scheme using attributes that looks pretty cool.

Another aspect of the server side is to choose a transmission protocol. I know you mentioned XML already, but you might want to reconsider. XML parsers vary greatly between browsers. One browser might make the document root the first child, another one might add a special content object, and they all parse whitespace differently. Even worse, the normalize() function doesn’t seem to be correctly implemented by the major browsers. Which means that XML parsing is liable to be full of hacks.

JSON is much easier to parse and more consistent in its results. Javascript and Actionscript (Flash) can both translate JSON directly to objects. This makes accessing the data a simple matter of x.y or x[y]. There are also plenty of APIs to handle JSON in every language imaginable. Because it’s so easy to parse, it’s almost supported BETTER than XML!

Client Side – The first issue you’re going to run into is the fact that no one understands how to write Javascript. ESPECIALLY those who think they do. If you have any books on Javascript, throw them out the window NOW. There are practically no good books on the language as they all follow the same ‘hacking’ pattern without really diving into what they are doing.

From the lowest level, your team is going to need remedial training on Javascript development. Start with the Javascript Client Guide. It’s the de facto source of information on the language. The next stop is Douglas Crockford’s videos on Javascript. I don’t agree with everything he has to say, but he’s one of the few experts on the language.

Once you’ve got that down, consider what frameworks, if any, you want to use. Generally speaking, I dislike stuff like Prototype and Mootools. They tend to take a simple problem and make it worse. None the less, you can feel free to evaluate these tools and decide if they’ll work for you.

If you absolutely feel that you cannot live without a framework because your team is too inexperienced, then GWT might fit the bill. GWT allows you to quickly write DHTML web apps in Java code, then compile them to Javascript. The PROBLEM is that you’re giving up massive amounts of flexibility by doing this. The Javascript language is far more powerful than GWT exposes. However, GWT does let Java developers get up to speed faster. So pick your battles.

Those are the key areas I can think of. I can say that you’ll heave a sigh of relief once you get struts out of your application. It can be a bit of a beast. Especially if you’ve had inexperienced developers working on your Struts model. 🙂

Any questions?

Edit 1: I forgot to add that your team should study the W3C specs religiously. These are the APIs available to you in modern browsers. If you catch anyone using the DOM 0 APIs (e.g. document.forms[‘myform’].blah.value instead of document.getElementById(‘blah’).value) force them to transcribe the entire DOM 1 specification until they understand it top to bottom.

Edit 2: Another key issue to consider is how to document your fancy new AJAX application. REST style interfaces lend themselves well to being documented in a Wiki. What I did was a had a top level page that listed each of the services and a description. By clicking on the service path, you would be taken to a document with detailed information on each of the sub-paths. In theory, this scheme can document as deep as you need the tree to go.

If you go with JSON, you will need to develop a scheme to document the objects. I just listed out the possible properties in the Wiki as documentation. That works well for simple object trees, but can get complex with larger, more sophisticated objects. You can consider supplementing with something like IDL or WebIDL in that case. (Can’t be much worse than XML DTDs and Schemas. ;-))

The DHTML code is a bit more classical in its documentation. You can use a tool like JSDoc to create JavaDoc-style documentation. There’s just one caveat. Javascript code does not lend itself well to being documented in-code. If for no other reason that the fact that it bloats the download. However, you may find yourself regularly writing code that operates as a cohesive object, but is not coded behind the scenes as such an object. Thus the best solution is to create JSDoc skeleton files that represent and document the Javascript objects.

If you’re using GWT, documentation should be a no-brainer.