This is another set of JavaScript files I wrote to demonstrate the
basics of AJAX threading. It seems simpler than the AJAX
Queue, but
that's only because it leaves more of the "heavy lifting" to you.
Threading can be a real bear to implement, and is not for the faint
of heart (or messy of code).
The form below allows a fairly intricate demo of threading in action. It
can also be used to demonstrate the AJAX Queue. Like my other
projects,
complete source for a simplified version of this page is
available
here (Connects
to an aggregate SourceForge Project). The main threading support
is given in this
JavaScript file.
The way this works is you select a multitasking handler (either threaded
or queued), and specify a "processing delay" on the server. This
is really just a "wait time," and simulates a busy server.
You can have a log displayed below the demo. This gives more information
for the threaded implementation than for the queued implementation.
One thing you'll notice about the log is that, in Firefox, the Stage 1
Complex Callback is invoked before the log entry for the initial
call. That's because the initial call log entry isn't written until
after the program has returned from the initial function call, and
the Stage 1 callback happens immediately, but within the excution
thread of the initial call. Stage 1 is actually called immediately
after the HTTPRequest is made, but the HTTPRequest is logged after
returning from the request execution thread. It's just the way the
code was written.
Just so you know, I consider this code to be damn near useless, but everyone
seems all hopped-up about threading, so I did it. I guess I'll add
some thread control stuff like MUTEX and blocking, but it ain't high
on my priority list. I use the AJAX Queue Class in all my implementations.
It's a LOT easier to use, more predictable and easily meets the needs
of all my users. You have to have a particularly twisted mind to
design a site where a dozen different connections are going on at
once. Users hate that stuff. Just design a good, basic, usable site,
and they will love you for it.
QUICK NOTE: I made a mistake (the dangers of cut-and-paste programming),
in which I accidentally replaced the thread code with the queue code
for a few days. This was not reflected in the .zip file; only the
demo on this page. I apologize.
Demonstration of Threaded or Queued AJAX
NOTE: There is a 10-Second Timeout Set!
NOTE: I have not completed testing of this! It works well
on a number of browsers, but I need to bang on it a bit more with
IE6 and 7 (I'm a Mac user, so I tend to write stuff that works well
on Macs). If you use this, and you find problems, please let
me know. I'll
get right on it.
UPDATE: The test implementation (not the actual ajax_thread.js
file) is causing issues with IE7. Looks like a caching problem. It
may take a bit to figure out a good workaround. Until then, you'll
want to use a Gecko-
or Konqueror-based
browser to make all the little men spin.
UPDATE II: I've addressed the caching issues. Apple Safari
and IE6 won't spin all the little guys at once, so you'll just have
to live with only one spinner at a time. However, IE7 has fixed this.
Woo-Hoo! They've left almost every other blasted quirk from IE6 in
there, but fixed the REALLY CRITICAL THINGS THAT CAN BRING
DOWN HUMAN CIVILIZATION,
like animated background GIFs and transparent PNGs.
<clap> <clap> <clap> Jolly good show, what?
NOTE II: Opera 8 & 9 is really weird here. If you do multiple connections,
it seems to resolve them all at once. I think it's a bug. At first,
I thought it was doing all the connections at once, but I noticed
that it always resolves all the callbacks at once (in Threaded mode),
no matter when they were clicked. The AJAX Queue seems to be the
only reliable way of making sure that Opera is working properly.
UPDATE III: I solved the Opera issue. Apparently, Opera
ignores "no-cache"
headers returned by the target of an XMLHTTPRequest call, so multiple
calls with the same URL will result in the response from the first
call being propagated to all the rest of the calls. I solved it by
adding an "id" parameter to each call.
NOTE III: IN Opera, you don't get any callbacks until
Stage 3. In iCab, you don't get the Stage 1 callback, but you do get an
immediate Stage 2 callback. In IE, Safari and iCab, you won't get
any response text until Stage 4. In Safari, you don't get a response
until Stage 2, and that is not immediate (iCab is immediate). The
lesson here is that you can't depend on squat until Stage 3, and you can't
use response text until Stage 4.
