ajax bookmark problem

[Tony Rice]

I"d like to hear critiques on the following method for dealing with the
back button and bookmarkability problem with AJAX. Whenever I do
something on a page with ajax, I add to document.location.hash (which
doesn't reload the page but does include the parameters in a bookmark)
like so:

document.location.hash = document.location.hash + '&param=value';

So the URL gets updated like so:
http://host.com/cgi-bin/foo.cgi?cmd=bla#&param=value;
When that page is loaded from that bookmark, I'm converting that
information in the hash to the query (which reloads the page with those
parameters in the URL and drops the hash):

var hash = document.location.hash.substr(2);
if (hash.length > 0){
var searchadd = '';
var elements = hash.split('&');
for (i=0;i<elements.length;i++){
searchadd = searchadd + '&' + elements[i];
}
document.location.href=document.location.pathname +
document.location.search + searchadd;
}

Is it correct that the hash (i.e. everything after the # in the URL) is
only available client side?

The reload to incorporate those parameters in the URL is time consuming.
It takes an additional 60-90 seconds over a URL that doesn't need to be
corrected. Is there a better way?

[Peroli]

Hi Tony,
Try this tutorial [
http://dev2dev.bea.com/pub/a/2006/01...ck-button.html ]. Hope it
helps.

with regards,
Peroli Sivaprakasam

[Thomas 'PointedEars' Lahn]

Tony Rice wrote:

I"d like to hear critiques on the following method for dealing with the
back button and bookmarkability problem with AJAX. Whenever I do
something on a page with ajax, I add to document.location.hash (which
doesn't reload the page but does include the parameters in a bookmark)
like so:

document.location.hash = document.location.hash + '&param=value';

So the URL gets updated like so:
http://host.com/cgi-bin/foo.cgi?cmd=bla#&param=value;
Not really.

Zeroth, `document.location' is deprecated long since. Use `window.location'
instead.

First, you add to location.hash. However, location.hash may or may not
contain the leading `#' character, depending on the UA's DOM.

Second, there are user agents which do not honor RFC3986 in this regard,
meaning that a "&foo" is considered a part of the URI's `query' component
even if it is after the `#'. You should therefore omit the `&'.

Third, you have to escape (percent-encode) the content of the query-part or
the hash component.
When that page is loaded from that bookmark, I'm converting that
information in the hash to the query (which reloads the page with those
parameters in the URL and drops the hash):

var hash = document.location.hash.substr(2);
if (hash.length > 0){
var searchadd = '';
var elements = hash.split('&');
for (i=0;i<elements.length;i++){
`i' is undeclared, therefore either it is global or the assignment can
result in an error. Comparing against the unchanged elements.length in
every loop is inefficient.

for (var i = 0, len = elements.length; i < len; i++)
{
searchadd = searchadd + '&' + elements[i];
}
document.location.href=document.location.pathname +
document.location.search + searchadd;
However, this does not make much sense. First you split the fragment part,
then you concatenate it again.

You should choose another delimiter for the fragment part components, then
use `&' to join them and concatenate with location.search. Example:

window.location = window.location.pathname + window.location.search +
"&" + hash.split("_").join("&");
}

Is it correct that the hash (i.e. everything after the # in the URL) is
only available client side?
It appears so. Even with PathInfo, I have not been able to create a
request that includes the fragment component. However, I remember to
have read something about URL rewriting which used the `#' in a request;
unfortunately, I do not remember where.
The reload to incorporate those parameters in the URL is time consuming.
It takes an additional 60-90 seconds over a URL that doesn't need to be
corrected. Is there a better way?

Efficient programming.
HTH

PointedEars