battling with the back button

Recently, and also a few months back, I had a long drawn battle with the browser back button. There just seems to be something intrinsically broken with the web model using AJAX and that pesky button. In fact, even without AJAX, the back button in combination with form data seems to cause more than enough problems on its own. Consider my latest fight below.

My task was to repopulating a form when the user clicks on the back button. For those not familiar with the problem at hand, when a user clicks on the back button the page displayed is rendered from cache, and no request is made to the server. The actual page displayed when the back button is clicked may be in various states depending on both the browser being used, and the way this page was constructed in the first place, i.e. if it was rendered in stages with AJAX/JavaScript requests or just once when the page was loaded.

A simple, or not so simple, way to repopulate the form is by performing an AJAX call when the DOM loads, and either rendering the part of the page again and sending HTML in the response, or sending the form values back using JSON, etc.

Here I’m going to consider the first of these suggestions, but the problem I faced applies equally to the second (I think!). Let’s suppose that we make a request to the URL http://equivalence.co.uk/Step1/Index and that we are following some kind of wizard where we have “Previous” and “Next” buttons to navigate between the steps. Furthermore, let’s assume that the page rendered by default when accessing Step1/Index contains a form. Now suppose that we click the “Next” button and navigate to our new URL, say http://equivalence.co.uk/Step2/Index, and on this page we decide to hit the back button. As I described previously, on reloading Step1 we make an AJAX call back to the server, and importantly, we send the request to the same URL as the page we are currently on, i.e. Step1/Index.

When receiving this request on the server we check whether it’s an AJAX request or a simple GET then render accordingly. It’s probably reasonable to ask why the hell I was doing this, well if the server received an AJAX request there was no need to render the whole document again as I am only interested in the form element, but on the GET request I wanted to render the whole page.

However, this is where I ran into a little problem. Now suppose that we click the “Next” button again to move to Step2/Index and once again hit the back button. What is displayed?

Well as a surprise to me it was only the form, i.e. the response returned by the AJAX call, not the full page, no HTML head, nothing, just the form. Now that I have seen this behaviour, I totally understand why this is happening; the browser checks for the most up-to-date data sent for this URL, which in my case corresponds the AJAX request when the back button was hit previously. For some reason I just didn’t expect this – incidentally this was the behaviour on Firefox, I’m not sure what happens in the other browsers. As a result, when I was making the AJAX call I had to change it to make the call to “Step1/Index2” instead, now everything worked fine – I think maybe supplying a random get parameter to the original URL may also have worked.

So there we go, that’s it! Exciting post? Maybe not! Hopefully this helps someone though. It’s always something to bear in mind.

PS I’ve ended up with the weirdest problem ever whilst typing this entry in Google Chrome, it’s somehow messed up the keyboard mapping. As an example the top row on a QWERTY keyboard types as “azertyuiop^$” and you have to press shift to get the numbers. Strange.

more json and java

My post yesterday was actually intended to be a placeholder where I was planning to include a build of Douglas Crockfords Java JSON library that I have been using on some recent projects. However, I seemed to get carried away while writing and, as you can see, ended rabbiting on more than I intended. The result of this was that by the time I got to the end of it, I could no longer see where my original point fitted in to the discussion.

For the record, there are other Java JSON libraries (http://json-lib.sourceforge.net/, and http://oss.metaparadigm.com/jsonrpc/ to name two) but these are way way way too complicated for a simple application, and/or also have far too many dependences. The files in the jar file included at the end of this post work out the box, no need for other libraries.

So, anyway, today I thought I may as well get round to putting this jar file up on this site . This is not something that you can’t get elsewhere but I wanted it easily available for ME. Also, if like me, you are happy just to get a jar file, and really don’t want the hassle of building the (small) library, then you can just get it from this ere blog; at the time when I built this I could only seem to find the source, hence why I thought I may as well build it myself and host it. The javadoc for the code can be found at http://www.json.org/java/ and the link to the Java jar file I created can be downloaded using this link. If anyone has any issues with me hosting it then let me know and I will take it down, otherwise enjoy it.

Java JSON Library jar file

json is where it’s at

Well people I must say that I have come to LOVE JSON quite a bit in the last few months. Having used in on several projects both in work and in play.

However, not so long ago, I used XML for my configuration and data passing needs. I have always pretty much hated (YES! I said it in public) XML. Everything you do with it just seems loooooooong and verbose; a bit like the applications that (over)use it.

I mean we could just abandon structure altogether in a document and save time by not tagging anything, but where does that get us? Nowhere I imagine. It’s nice to have structure, just not an overwhelming amount that XML provides, especially when you only need it for are some simple config files, or sending messages between processes. XML is especially wasteful of space when you have a rather large file with a structure like below, multiplied by 10,000:

    <person>
       <id>1</id>
       <pref>8;3;4;5;6;7;9;10;11;13;17;18;19</pref>
    </person>

The above is data basically representing a list of choices, in strict order, for a person with id 1. So, person 1 prefers person 8 to person 3, person 3 to person 4 etc. To me it was better than what people used before XML, and let me tell you is still used now, which is:

1 3 4 5 6 7 9 10 11 13 17 18 19

Yes this is simple, clean and has no “spare” characters being used. However, when you have a problem with person number 7868, it makes debugging a little harder. It also makes changing person 7868’s prferences also very difficult.

With JSON this can be done as follows:

{ 'id' : 1,
  'prefs' : [1,3,4,5,6,7,9,10,11,13,17,18,19]}

It just sits as a very nice compromise between the latter schools of thought. I realise that this may seem very specific but I’m certain that it’s true in general. Not only is it less verbose, it is also easy to integrate with JavaScript on the client side of any web app, and for me with a little nurturing JavaScript is gonna be where it is ALL at it a few years time.

So the next time you go to use XML in a project, have a think first and see if JSON is your new friend.