Polling vs hidden iFrame for Ajax history

0 votes
asked Nov 24, 2010 by jojo


Detection of hash change in the URL and fixing the forward/back button are two requirements for libraries that deal with Ajax history. There's two schools of thought for implementing these libraries. You can have a poller constantly check the URL (bad browsers don't have the onHashChange event). Or you can use a hidden iFrame to add points in your browser history. One may think the hidden iFrame is better than polling, but the hidden iFrame does not update the outer browser's URL. So if a user wanted to share her current state in the web application, she would always be sharing her initial state.


Is there any technique for Ajax history that both doesn't require polling and also updates the main browser's URL?

2 Answers

0 votes
answered Nov 24, 2010 by matt-briggs

How about a combination of the two techniques? change the url, as well as use the iframe. ignore hashChanged (on good browsers), and just parse the hash code on dom:ready

0 votes
answered Nov 24, 2010 by strife25

Looking at your comments from the original question, I would recommend using the iframes method for IE and polling for other browsers.

Check out Real Simple History if you are looking for a library that handles this specifically and you want a basis to help roll your own.

If you are just looking for the functionality of keeping your page's state in an Ajax UI, dojo supports this with the dojo.hash() shim. This method creates the onhashchange event for browsers that do not support it and manages the state of your back button. It uses a mix of polling and iframes depending on the browser (iFrames are used specifically in IE versions < 8).

Welcome to Q&A, where you can ask questions and receive answers from other members of the community.
Website Online Counter