I do this with a simple javascript call, separate from the ajax call - I don’t modify all my ajax request handlers to do their own checking for member login, and their own event handling (in the success function) if the member is not logged in.

I currently have a home-grown synchronous ajax call to check for logged-in-ness that I use before initiating the specific ajax action. I was hoping to drop the home-grown stuff and just use YUI - but it appears I can’t, since YUI doesn’t support synchonous calls. Is there some better YUI way to handle this use case?

While you have a valid point, I disagree that current behavior of XMLHttpRequest is a problem or faulty design. A true async operation should return when the operation is finished. It shouldn’t have dependency on when the operation is invoked.

Previous comments has shown that it is easy to cope with the async behavior to achieve your goal. But if XMLHttpRequest is designed to have response return in invocation order, it will be very difficult to achieve true async operation, therefore make it useless on many other use cases.

For example, you have a database application with a list view and a record view. Records are locked when loaded and unlocked when unloaded. The locking can be done server-side, but the unlocking needs to be done via a JavaScript request.

By the time the request is complete the page is gone. If there was a callback function, it’s gone. If the loading of the next page is affected by the lock status, there is no guarantee that the XMLHttpRequest is finished before it starts loading. You can’t just put the unlock function on the list page, or in the link, because you don’t know what the user is clicking on or if they might want to have two records open.

My solution was to track the XMLHttpRequest object in a variable (we’ll call it xhr).

When an attempt to make a new Ajax call is made I check xhr to see if it is null. If it is not I call xhr.abort() to kill the request (now it will not return, out of order or otherwise). Then I set xhr = null and make the new request storing the new XMLHttpRequest object in xhr.

var xhr = null;
function MakeAjaxCall() {
if (xhr !== null) {
xhr.abort();
xhr = null;
}

xhr = new XMLHttpRequest(/* proper settings */);
/* more code to complete the XMLHttpRequest */
}

I also add a delay when making Ajax requests from a UI component. This gives the user a tiny moment to cycle through selects without my code making and aborting a lot of Ajax calls.

var select_change_timeout = null;
var reasonable_delay = 100; // or something reasonable
var select_element = document.getElementById("my_select_element");
select_element.onchange = function () {
if (select_change_timeout !== null) {
clearTimeout(select_change_timeout);
select_change_timeout = null;
}

select_change_timeout = setTimeout(MakeAjaxCall, reasonable_delay);
};

Disclaimer: code samples are simplified and untested and may not work for you.

Synchronous Ajax calls lock the browser. If for some reason the request did not return, the only way to unlock the browser is to kill it from Task Manager. Sync calls are not considered good programming form. And dont take it from me, here is a blog o….

Items n links Libs…