On Aug 28, 10:30 pm, oravecz <[EMAIL PROTECTED]> wrote:
> Is there a more "raw" form of .ajax (or get, .post) that will expose
> the XHR method to the success (or error) handler?
The current XHR protocol only has a nreadystatechange handler. I'm not
up to par on how the W3.ORG working groups procedure is done (I'm more
familar IETF), I believe there is a working draft is extending the
protocol with more callback handlers such onSuccess, OnError, etc.
The current release does not have these.
However, jQuery emulates these similar callbacks based on the state of
the XHR.
> I am attempting to convert an application to jQuery that has a
> proprietary server module that uses a wide range of HTTP status codes
> for certain nuances on the client.
Same here.
If all you want is the status code, Mike's suggestion is good enough.
> I notice that the XHR is returned when an ajax method is invoked:
>
> var xhr = $.get(uri, options.parameters, options.onSuccess, 'xml');
>
> I suppose I could create a new class that encapsulates the ajax call
> and makes the XHR method available as a private variable.
It does return the XHR object, but it begins running at that moment.
You can do something like this as a quick monitor:
var xhr = $.get(uri, options.parameters, options.onSuccess, 'xml');
var iTimer = 0;
function monitor() {
if (xhr.readyState) {
log("state: "+xml.readyState);
if (xhr.readyState == 4) {
clearInterval(iTimer);
return;
}
}
}
iTimer = setInterval(monitor, 1);
If you are not familar with the JS memory model, this works because
the xhr and iTimer variables are global to the inline function
monitor()
> If I provide
> my own onSuccess handler proxy, I could gain access to the XHR
> variable and pass it along. I am hoping that jQuery or a plugin may
> have already taken care of this.
well, Mike's answer shows that the the internal complete() callback
does pass the object to you, so you can use that.
But overall there are things that jQuery "removed" from the XHR
protocol functionality that limits applications.
For example,
1) for us a 403 is not necessarily an ERROR.
2) There are designs where you want to get state 2 or 3, These are
lost via JQuery. You only get state 1 and 4 which is perfect for most
simple AJAX calls. If you use the above monitor() you will see this.
3) It doesn't have a built-in "monitor" that allows you to do things
you might need in 2.
4) It depends on a timer polling concept to watch the current XHR
state.
and a few other goodies.
Anyway, I'm working on a plug-in replacement and if you are
interested, I am going to need a few beta testers. So if interested,
keep an eye on any announcement I make here.
--
HLS
