Monday, November 20th, 2006
Ajax Queue JavaScript Class
Category: JavaScript
, Library
Chris Marshall has a background in writing low-level asynchronous code in C++. When he started to write Ajax code he saw the need to manage concurrency and created a Ajax Queue Class that handles all of this for you.
An example using the library is this file browser where you see the root of the library:
JAVASCRIPT:
-
-
function callout ( in_request, in_id ) {
-
var url = 'ajax_file_browser_server.php?'+in_request;
-
g_ajax_obj.CallXMLHTTPObjectGETParam ( url, receive_browse_results, in_id );
-
}
-
3.9 rating from 69 votes
I think a Web developer should care about multiple requests (disabling forms, buttons, links when is necesary and not allowing multiple redundant interactions with the same element at the “same time” for each user).
This library seems to be cool but we need secure, safe and optimized applications too … this is the Web, with its “old” protocol and not a C++ asynchronous interaction.
It’s only my humil opinion.
Well, at least someone has spent a lot of time not learning JavaScript naming conventions…
The code snipplet was entirerly unintelligible. I sincerly hope it’s been taken out of context.
Here are Javascript threads:
http://www.javascript-examples.com/javascript-threads/
my own queue/batch-ajax-framework seems to be much more easy to use…anyway.
What a bunch of crappy code, this can be done so much easier!
Sometime, it’s an important thing to control functions’ order. And javascript-threads will be one of the important parts of RIA framework.
I search google, and find a thread class including start, sleep, suspend, resume, … That’s great! I will use it in asyc ajax callback.
Just curious. Not sure I understand the point. HTTPRequest is an HTTP communication standard, and is actually not a part of JavaScript. The HTTPRequest object is really just a “facade” that JavaScript slaps onto the low-level functionality, like the “system()” calls in C.
HTTPRequest is only capable of handling a single request at a time per window/frame. That’s not a JavaScript limitation. It’s an HTTP limitation. I looked at some of the “threading” stuff, and it all winds up doing the same thing “under the hood.”
This is simply a low-level interface to that. It is meant to act as a “driver,” and uses pretty much the same techniques you’d use in a UART driver. If you want to add “threading” to it, then you simply create a wrapper, and this takes care of the lower level. Consider this to be a “Transport layer” in the OSI model (Like the “TCP” in “TCP/IP”).
It really shouldn’t be considered equivalent to C++ threading, but could be used as a basis for that. The whole idea of a layered approach to communications is to make each layer’s quirks and limitations opaque. This is simply a facade to some of the limitations of HTTPRequest.
I’m sorry that it seems scary. If the code snippet shown to you in the example here is frightening, then BY NO MEANS should you look at the main JavaScript file. You’d never recover.
I was able to develop a similar library for threads. I was not completely correct about the threading issue, which is nice, because it allowed me to write this.
I don’t mind being wrong if it results in good things like this.
NOTE: The demo code (not the core thread code) won’t work quite right on IE6 or IE7. This appears to be because of a caching issue (the code uses CSS background-image attributes, and IE likes to cache these). I’m working on a workaround now, and should have the demo tweaked soon.
It’s very kewl if you use Firefox.
Everything works, and works very well indeed.
That being said, I find this threading code to be almost worthless. I don’t go AJAX-crazy in my implementations, and find the queue to be far, FAR more useful, reliable and simple to use in real-life applications. I have no intentions of replacing it with the thread driver.
The Ajax Queue Class works, is reliable, and simple to use. It has saved me a lot of time when setting up a site quickly. Thanks, Chris.