The keepAlive function calls the PHP page I'll describe later. For now, understand that any URL could be used, and this one should return either "OK" or something else. The TMPL_VARs are again supplied by the publishing system to track the current editor and article.
The reason for the if is that even though Microsoft created XMLHttpRequest, Internet Explorer doesn't actually support the function without the use of ActiveX. Firefox, Safari, and other browsers do support it, however, and so we first check to see if one of those will work, and only fall back on the ActiveX approach if that fails. In either case, the idea is the same: we instantiate the object, tell the browser to call the processReqChange function if anything happens, and then open the URL and send it a null to get it moving.
This is where the asynchronous part comes in. The javascript function ends and the browser goes along its merry way. If the XMLHttpRequest object never returns, the browser is not hung up. When the object's state does change, the processReqChange function is fired off.
There are several different "ready states" the object can be in, so we first check to make sure we're in readyState 4, meaning we're finished. Given that, and given that we have control over the server side, the most likely result is that our status is 200, the standard HTTP status for "success." If that isn't the case, something unusual must be happening, so we'll display some error information and clear the interval so we don't keep hammering the server.
Most likely, though, is that our HTTP GET has finished successfully and returned with "OK" or something else. If the result is "OK", we know that we've been granted exclusive access to this article, so we can clear the warning message, enable the Save button, and set the keepAlive interval to a more reasonable rate to ensure that we maintain our exclusive access to this article.
Warning! You might think that using the same object name with a different interval value would reset the existing interval, but in Internet Explorer at least, that isn't the case. The intervals are cumulative, so you must first clear the existing interval before setting a new one.
If the result from the GET is anything other than "OK", that means (because of the PHP code we'll get to in just a few paragraphs) that this article is locked by someone else. In that case, we'll set the contents of that div to explain that the article is locked and clear the interval so we don't bother even checking any more. After all, by the time this article isn't locked anymore, the contents will likely have changed, so we want the user to refresh the page. We could actually refresh the contents automatically, and we probably will in a future version of this code.
Article comments
1 - Aaman
I wish that Ajax book was cheaper:)
Incidentally, is this true AJAX, does the reliance on PHP and SQL not mean a new paradigm, not reliant on XML?
2 - Phillip Winn
It's still XMLHttpRequest, so all three elements of AJAX are present. The PHP and Mysql are, I think, incidental. It could as easily be anything else, or an external webservice, on the "back end."