On Aug 24, 12:48 pm, "John Resig" <[EMAIL PROTECTED]> wrote:
> No, this is final - the blog post contains the full release
> notes:http://jquery.com/blog/2007/08/24/jquery-114-faster-more-tests-ready-...
Yes, a few mins after my post, I saw the jQuery.com page was updated.
Cool.
> Do you have any specific Ajax improvements?
Yes, I still fussing around to get my design thoughts right to reduce
it down to a generic applicability, but this came up in applying
ajax to our web authentication system. We had the ideas I will
highlight in early raw ajax "proof of concepts." Using jQuery, we
lost some of that, even when using .ajax() to customize it.
Again, this might be already possible. I don't see it though.
1) add an optional callback hook to watch the progress of the call
state.
The ajax() function only watches for state 4.
Maybe adding an else block to call the optional state hook If the
state hook return false, the call should be aborted. Also the call
should only be done iff the state changes. This will reduce redundant
callbacks.
People can code it like so:
$.ajax({
type: "GET",
url: "someurl",
statechange: function(obj) {
$('#monitor').text("State: "+obj.readyState)
return true;
},
complete: function(obj, status) {
},
success: function(msg){
},
error: function(obj, status, e){
}
});
}
2) HTTP response codes
This is where I am working out more to see what is going on with our
web authentication system and also how to best address it.
The visual "as is" implementation effect is an "403" response code
erroneous being by httpSuccess() as a failure for a web "log off"
concept, and also a redirection 302 can be erroneously interpreted as
an error.
The current function is:
httpSuccess: function( r ) {
try {
return !r.status && location.protocol == "file:" ||
( r.status >= 200 && r.status < 300 ) ||
r.status == 304 ||
jQuery.browser.safari && r.status == undefined;
} catch(e){}
return false;
},
and from this I see it has hard code for [200,,299,304] as success.
In my opinion, that is an server implementation design issue, not
something the jQuery protocol should decide as an error or even as
success.
So basically I am trying to see what is best to do this in general.
I was thinking of where you allow for status based call backs that can
return the true or false result:
$.ajax({
...
status302 : function(obj) { return true; },
status403 : function(obj) { return true; },
});
}
or done via an json object:
$.ajax({
...
statusSuccess : [302, 403],
});
}
This will allow for implementations with speciifc response codes to
define what is considered success or an error.
In theory, you have two types of errors - hard and solf:
hardError: function(obj, status, e){
// something fundamentally wrong
// - parsing error perhaps?
// - DNS error
},
softError: function(obj, status, e){
// server response received,
// httpSuccess() return false
},
Thats the gist of it. Like I said, still studying code, maybe all
this is possible right now. I can see an httpSuccess() overide easily
being done, but not the state change hook.
--
HLS
