Maintaining State with AJAX
One of the most difficult parts of writing complex, AJAX-enabled web applications is maintaining state throughout the user experience. Since, by nature, AJAX gives us the ability to do completely unstructured navigation with real-time changes, maintaining state has become increasingly complex.
Recently, I was working on an AJAX-aware process where the user would select from a set of criteria for searching system inventory in a future version of RSP. The tool is designed to allow systems administrators and managers to quickly compare hardware configurations (along with other hardware-related features). In setting the criteria, the user was changing the way a table of hardware configurations was appearing, all in real-time on the same page. One of the difficulties was keeping the state of the user-chosen criteria consistent between page updates.
The solution I came up with was to generate a “state” in Javascript whenever the user changes their set of criteria, then “serialize” this state into a string suitable for POST’ing to the backend (where it’s processed by a Java controller).
Without AJAX, state is maintained based simply on where we are in a site hierarchy. We click a link on a page and we’re transported to a different file. With AJAX, it’s not so simple: clicking a link often means the user stays on the same page but changes the behavior of a particular process, or moves an element to a new position. Often it’s up to the developer to devise a way to maintain state.
In my case, the visual aspect (what the user is able to modify) is written in JSP, Javascript and plain-ol’ HTML; the backend uses Java and the Spring framework. The difficulty isn’t in the logic: it’s in the more mundane task of sending the changes the user makes to the backend. A “chain” quickly develops: the user clicks an HTML element to add new criteria, which calls a Javascript handler to run the AJAX update command to the backend; the backend receives it within the Java framework and is processed by a Controller; the result is passed to a JSP page and displayed.
The problem is: I have to write the same state logic twice, in two different languages. First, I write the “encoding” part in Javascript, whereby I devise the user’s state based on the form elements they have selected, and then transmit that to the backend via a string. On the backend, I create a “decoder” for this serialized state string. As the backend changes the state, I must then send the new HTML code back to the client to repeat the process.
Luckily, in my case, changes to the user’s page only happen based on the user’s actions. Consider an example where the user may make changes, as well as third parties – and the results from either must appear on the user’s page. I can readily see how a community drawing application might run into problems (one user draws a square; another draws a circle; both shapes must appear simultaneously on both user’s screens). This would require encode/decode state mechanisms written for both the front and backends (that’s writing the same thing twice in two different languages). Rather annoying.
