XMLHttpRequest object suggestion

This is documented further at a post on my blog:
<http://www.markkawakami.com/entries/1248.html>

As I'm sure you're well aware, one of the challenges facing developers
of websites that utilize the XMLHttpRequest object (or the current IE
equivalent) is the bookmark/back button issue. In short, because the
state of the page changes independent of the URI, bookmarking and
using the back button can potentially have unexpected or undesirable
results.

I think this can be fixed by allowing another optional parameter,
either in the open() method of the XHR object, or set as a property of
it, which would be a boolean that indicated whether the URI should be
substituted in the user's location bar (and added to the history
stack) when the request is successfully completed. In this case, if a
user were to bookmark the page after the request has completed, they
would be bookmarking the URI of that request, rather than the URI of
the originating page. In similar manner, the back button would return
them to the last page in their history stack which would be either the
originating page or a previously substituted URI.

The solution works out extremely well when combined with the
setRequestHeader method. By setting a request header with some
specific value (Rails has started using the "http-accept" header, I've
been using a custom header), the back-end can be told that a given
request is an XHR request rather than a regular page request, which
allows it to return just the data the calling script needs. WIthout
the header, it can return (or redirect to) the appropriate content as
a fully-formed HTML document. So when retrieving that URI via either
bookmark or back-button, the web server would know the correct content
to send based on the presence or absence of a given value for a given
HTTP header.

An additional benefit this method has is that is highly backwards
compatible and completely optional. Sites that have implemented other
methods for dealing with this issue (or haven't implemented any method
at all) will still find their existing scripts to work as expected.
Only by intentionally setting this flag will a URI substitution take
place. However it takes backwards-compatibility (and overall
accessibility) a step further by encouraging traditional HTML
representations of content that may have otherwise only existed as XML
or JSON data. Once you have that, it's trivial to make most actions
that would be called via XHR if available also available to non
XHR-capable browsers.

Thank you for reading this, I apologize for it's length (and the
length of the linked post), but I do think this is an elegant solution
to a thorny problem and I hope you give it some consideration (if only
to point out why it won't work).

-Mark Kawakami



--
Mark Kawakami
mark.kawakami@gmail.com
http://www.markkawakami.com

Received on Tuesday, 18 April 2006 05:35:27 UTC