Coding In Paradise

I'm back at the Berkeley Used Computer Store, renting and hacking on a Mac to get access to the Safari web browser.

Like I have been the last few months in different browsers, I'm experimenting with getting reliable control of and notification of changes to the browser's history, including changing the browser's location using anchors.

Why am I tracking down such obscure things? Well, for one, having a reliable way of dealing with the back and forward buttons and bookmarking means we can have these in AJAX/DHTML applications. My goal is to create an extremely simple API, named DhtmlHistory, that has two very simple methods:

addHistoryListener()
add(newLocation)

Whenever a history change occurs within your AJAX application (i.e. if the user presses the back or forward buttons), your listener gets notified. When you add() a new location, such as add("page:foobar"), we add this as a hash value on to the page:

http://somepage.com/MyAjaxApp#page:foobar

Then, when the user moves around with the back and forward buttons, your listener gets called back.

Here's whats great about the API above: it doesn't dictate how your app handles these events. If you want to make them simulate Undo/Redo actions, go ahead. If you want to tie all of your XmlHttpRequest events into your history, more power to you. If you want to tie a mix of user actions and network activity in, you can.

I believe this is the way forward when it comes to bookmarking and history activity in AJAX apps: you decide. History and bookmarking should be decoupled from network activity, since AJAX fully breaks these now. All users expect is that back and forward should work, as well as bookmarking; your particular app needs to decide what this means.