A well-known technical limitation of Ajax is the inability to update the URL in the Browser’s address bar without having to reload the whole page. While this is basically a good idea (imagine the phishing opportunities by pretending my site’s URL is apple.com), there are some Web2.0 use cases where this may be quite useful.
Imagine a simple guestbook webapp where all posts are simply displayed vertically beneath each other. Since this could generate a huge page, it’s a good idea to use a paging mechanism with
next links. To ajaxify that application, we’ll put all comments in one containing div element and only update the content of that div when clicking a
next link. Obviously, the URL will never change while scrolling through the guestbook and always be like
Thats fine… but what if there’s an interesting comment on page 67 which I want to share (perhapps with a buddy through IM)? In a Web1.0 context, I’d just copy/paste the URL while having page 67 displayed. That URL would have a POST argument like
?page=67 allowing that URL to point exactly to the content I saw when I was grabbing it. However, with my ajaxified version, I don’t have this parameter and thus everyone would have to scroll through the pages to find the post I wanted to share. Even if I’d display direct links to each page, I’d still have to tell my buddy to go to page 67 and to look at the 5th post on there. Permlinks are a workaround but are far less intuitive and look different on every page whereas the URL always sits in the browser’s address bar and just waits to be grabbed. Wasn’t Web1.0 much simpler?
Now imagine it would be possible to rewrite the URL so that whenever I click one of the prev/next links, the URL displayed in the browser would contain all parameters needed to get exactly the same state I’m in when copying the URL. Bookmarking is exactly the same and suffers from exactly the same issues.
Note that I’m assuming we’ve got web developpers that know what they do, how they do it and what implications this URL manipulation may have in terms of tech and coherence. Well, unfortunately for those Web developpers, such a direct URL manipulation isn’t possible. At least not without having the browser arbitrary reloading the page. Many forums where this question rose up ended up with that conclusion.
However, if you take a look at this page (taken from Apple’s brand new .Mac WebGallery WebApp), you’ll notice that, when clicking on the little color dots on the bottom right, the URL changes, but the page doesn’t reload.
Now, how did they do that?
document.location.hash = "page=67";
On the page “http://mike.meessen.biz/guestbook/index.php”, that would result in the following URL being displayed in the browser:
From here, it’s kinda simple: put your http-POST-like argument list after the hash, make your application recognize these after-hash arguments when the page is loaded (which will be hack-the-hell-around again) and you’re done.
Pretty cool, huh?
[ Update ]
With HTML5’s History API, you can achieve even more native-looking URL manipulations without the need for a ‘#’ in the URL 🙂 Note though that the browser needs to support the History API (the major ones already do), and that you still need to provide the “real” URLs behind the ones you “fake” server-side to achieve true bookmarkability. Check it out: http://diveintohtml5.org/history.html.