Put on Your X-Ray Specs: Converting Web 1.0 to 2.0

Dietrich Kappe, Thursday, March 6, 2008 @ 12:24 pm

I've blogged in the past about converting Web 1.0 to Web 2.0. There were and still are three options:

1. The Christmas Tree Approach - decorate your existing Web 1.0 application with lots of snazzy Ajax widgets. It's quick, but it's a bear to maintain.
2. The Version 2.0 Approach - scrap your existing app and develop a Web 2.0 version from scratch. This can take a while and suffers from the same issues that all version 2 projects do, i.e. if version 1.0 has evolved over time, capturing full requirements may be challenging.
3. The Resurfacing Approach - keep your backend logic, but rewrite the interface as a single page, desktop-like GUI.

This last approach has many advantages: it's quicker and less expensive than #2, but easier to maintain and gives a more unified user experience than #1. It also has some of it's own pitfalls. Mostly, the issues are around some of the hidden assumptions of a Web 1.0 applications that expects all interaction to occur through a postback.

So, what's the plan? How do we go about converting our 1.0 app via resurfacing? To do this you have to put on your X-ray specs, so to speak, and look at the bones of your application. If you're already using an MVC framework, your ahead of the game. So, what are the analytical steps? 

1. What are your controllers? If you're using an MVC
   framework like Spring MVC or the venerable Struts, then identifying
   your controllers should be easy. Otherwise, a good rule of thumb is
   that anything that takes parameters via a GET or a POST, is likely a
   controller. If you're storing lots of stuff in the session or in
   cookies, you may need to dig a little deeper.
2. What are your
   views? Again, an MVC framework makes this sort of thing easy to
   identify. They are the JSP's or other sort of dynamic pages that
   display the results of your interaction with the controllers. In some
   cases there may be a shortcut, where a view is not distinct from the
   controller, i.e. the view URL takes parameters. Make a note of this.
3. Which
   of your controllers and views are stateful? In other words, if you have
   an application that allows you to reserve hotel rooms and then book
   them, does it make sense to call the controller that handles payment
   without first having stepped through the workflow that involves the
   creation of an itinerary, etc.? If you're keeping lots of state
   information in the application server session, this is a clue that you
   probably have some stateful controllers and/or views.

If you
have an application map (also sometimes know as a site map) that shows
the various interactions and workflows, this can be very helpful in
identifying the elements discussed above.

Why have we gathered
all of this information? What's the next step in the plan? The
controllers are going to turn into services, i.e. they are going to
lose their workflow/navigation function, the views are all going to turn
into XML, and the resurfaced front-end will orchestrate these services
together.

Over the next couple of posts, I'm going to walk
through a sample Web 1.0 application and look at a few of the issues
that stand in our way:

• How stateful controllers can cause problems.
• Moving workflow from the server to the client.
• 404, server timed out, reload, and other Web 1.0 usability features
• How to handle history now that your pages are gone
• Security and the Web 2.0 application

Technorati Tags: ajax, web20

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment