it can be super simple:
Code:
function aGet(turl, callback) {
var XHRt = !window.XMLHttpRequest ? new ActiveXObject('Microsoft.XMLHTTP') : new XMLHttpRequest();
XHRt.onreadystatechange = function () {if (XHRt.readyState == 4 && XHRt.status == 200) {callback(XHRt.responseText, XHRt);}};
XHRt.open("GET", turl, true);
XHRt.send("");
return XHRt;
}
function redraw(){
aGet(location.href, function _ajaxCallBack(html){
document.body.innerHTML=html.split(/<\/body>/i)[0].split(/<body[^>]*?>/i)[1];
});//end aget cb
}//end redraw()
var secs=30; //adjust this to # of seconds between updates
setInterval( 1000 *secs );
this simple example works surprisingly well on simple pages.
you can be more precise than the whole body; updating just the region you need. you can do this by string or dom. one trick is to hard-code 2 comments in your content div, to mark the content you want:
Code:
<div id="main"> hello world </div>
becomes
Code:
<div id="main"><!--CONTENT_START--> hello world <!--CONTENT_END--></div>
you can then refine the above demo's callback code considerably:
Code:
document.getElementById("main").innerHTML=html.split("<!--CONTENT_END-->")[0].split("<!--CONTENT_START-->")[1];
try to avoid redrawing the whole page to avoid bad side effects:
- scroll bar jumps
- images flicker, possible re-pinging the server and wasting bandwidth
- some scripts might stop working
- window title doesn't change
- scripts don't re-load
- jerkiness of re-loading images can move the screen up or down
- selections are lost, as are any filled-in form boxes.
- can take a while and use a bit of CPU, especially on mobile
the worst complications arise when trying to do this all flawlessly if you're using javascript on the replaced html. any bound events will be lost. css and links should all still work ok...
depending on the scripting in use, you can often call the onload() event again to re-bind the new html with the event handlers. jQuery's ready() events poses further challenges, because it is not reachable once the event fires. you have to re-add your jquery plugin files to the dom once the content changes. they script files should be already cached by the browser at this point, so performance is much better than the real page load sequence.
you can work around this many ways.
-don't use javascript in the content, and it works 100%
-use ajax and localStorage to memorize the scripts so they can be eval()'d instead of re-added
-use an iframe to point to a simple html chunk that needs refreshing.
-modify any script files to make sure they have a reachable ready handle.
in jquery, you can usually do this at the top of a plug-in file by sneaking an assignment into the ready() call:
becomes
Code:
$.onloads=$.onloads||{};
$(onloads['myplugin']= function(){ ...
you can then loop through $.onloads and re-fire the scripts that give the page life.
without jQuery, things can be simpler or more complicated, depending on the scripts used.
just make sure that what ever scripts you use can be re-added many times without breaking OR that you can reach the needed onload/ready/init functions.
finnaly, i should mention that if you only update textNodes, the events bound to existing elements will stay intact after the update. by careful use of selectors or extra attribs, you can replace each text piece one-at-a-time using element.textContent='something'. this approach is preferred for things like clocks and status updates as it's the least intrusive to the rest of the page. depending on your template, you might be able to iterate your before and after code's elements instead of using extra markup.
i didn't event mention some of the neat template engines out there these days; they might be worth taking a look at as well.
there's 1001 ways to do it; expect some debugging to get things perfect...