My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Saturday, October 20, 2007

[COW] locAction - hash JavaScript location wrapper

One of the problems using JavaScript and Ajax is history managment and location behaviour.
A good solution was found by backbase many months ago, using reserved hash location property to manage correctly interactions and history itself.
This COW should be used to manage hash property as a full compilant location, allowing developers to know pathname, search (query string) and in some cases (JavaScript and Opera) hash itself too.

You can view a demo in this page comparing native location and wrapped one using locAction callback.

Please note that backbase too removed this practice from its site (which problems?) but my locAction proposal is compatible with every kind of JavaScript compatible browser (of course, IE4 and NN4 too).

These are few examples:

// basic example - standard location

href: http://localhost:80/?key=value&other
protocol: http
hostname: localhost
port: 80
pathname: /
search: ?key=value&other
hash:




// basic example - locAction(location)
// using http://localhost:80/?key=value&other#hash

href: http://localhost:80/hash
protocol: http
hostname: localhost
port: 80
pathname: /hash
search:
hash:



// full example - standard location
href: http://localhost:80/mypage.html?key=value&other#ajax/page.html?other=key&value
protocol: http
hostname: localhost
port: 80
pathname: /mypage.html
search: ?key=value&other
hash: #ajax/page.html?other=key&value




// full example - locAction(location)
// using http://localhost:80/mypage.html?key=value&other#ajax/page.html?other=key&value

href: http://localhost:80/ajax/page.html?other=key&value
protocol: http
hostname: localhost
port: 80
pathname: /ajax/page.html
search: ?other=key&value
hash:

As You can see with location You can manage directly a parallel/alternative JavaScript/Ajax dedicated url, accepting GET variables as different paths.
In few words You'll have two different address, one for JavaScript disabled browsers and one for JavaScript enabled browsers.

Both locations, original one and generated using locAction, will have same methods too: replace, assign and reload but locAction() object should be always use these methods (direct assignment is not allowed, however native location direct assignment uses transparently assign method so it's quite tha same).

What else? locAction generated object shoud accept hash string but not with Internet Explorer or Safari (at least 3).

2 comments:

Roberto Saccon said...

Andrea, I experimented with a similar concept, I however tried to make the normal and the ajax url look as similar as possible, see example:

normal:
=========
http://foo.com/page/id

ajax:
======
http://foo.com/#/page/id

I tried to redirect (keeping state, from URL in a cookie) to ajax URL schema when an JS-enabled browser started with a normal URL, unfortunately that caused trouble and I have disabled the testpage I had running that, but will eventually look again into that probably with an approach as the yours, with links keeping both states ...

Andrea Giammarchi said...

Hello Roberto,
locAction concept is designed for graceful enanchment while your ajax example will not work with javascript disabled browsers (as backbase didn't redirect correctly with javascript disabled browsers).

The new idea of locAction is that You can manage separately two different version of sites starting from a compatible url schema.

To obtain the same result You could use a link like this one but it should be better to use a different pathname for JavaScript / Ajax interaction to simplify client/server interactions too.

It's quite difficult for me to explain better locAction power, however I hope someone will use them one day :D