Javascript : Non-halting Synchronous Server Function Call Trails
3 Comments Published by Brett on Tuesday, June 27, 2006 at 2:03 PM.
That title is pretty confusing. The main idea that I'm trying to pinpoint is that a client application can make synchronous function call trails (I'll explain later) without disabling the user from accessing the other parts of the application.
The way you do it is to use setTimeout and SyJAX (I'll explain in a bit) in conjunction. SyJAX is basically AJAX but without being split from the function process. Using SyJAX, a request is made and the process waits until the response is received. This is great for when we want a piece of information from the server to be stored in a variable in javascript, and that same function needs to return to another function, which needs to return to yet another function, and so on. The problem with AJAX is that it detaches from this function trail and the trail has to terminate. In a function trail that NEEDS a server response stored to a variable in order to continue SHOULD stay and wait for the server response (otherwise we lose the work that has been made in the trail). So here is where knowing XMLHttpRequest can be synchronous is so crucial. Our function trails can now stay intact as they move forward... but there is still another problem.
What happens if the function trail is sitting there waiting for a server response and the response never comes back? The user is now stuck with a disabled browser where they can't use any other functionality. We get around this by using setTimeout. SetTimeout is special because it gives us the capability of setting a function call up asynchronously. So in essence, we split the initial function call off from the main load and it takes on synchronous function calls from then on using SyJAX. This frees the user from having to wait for the function call trail to end and allows them to use the web site in other areas.
Effectively we have a asynchronous call to a synchronous function trail, instead of a synchronous call to an asynchronous function trail. I'm sure I will find additional problems with the solution as I use it more and more, but having this option definately alleviates some problems I have been faced with.
Brett Garrison
Steel
The way you do it is to use setTimeout and SyJAX (I'll explain in a bit) in conjunction. SyJAX is basically AJAX but without being split from the function process. Using SyJAX, a request is made and the process waits until the response is received. This is great for when we want a piece of information from the server to be stored in a variable in javascript, and that same function needs to return to another function, which needs to return to yet another function, and so on. The problem with AJAX is that it detaches from this function trail and the trail has to terminate. In a function trail that NEEDS a server response stored to a variable in order to continue SHOULD stay and wait for the server response (otherwise we lose the work that has been made in the trail). So here is where knowing XMLHttpRequest can be synchronous is so crucial. Our function trails can now stay intact as they move forward... but there is still another problem.
What happens if the function trail is sitting there waiting for a server response and the response never comes back? The user is now stuck with a disabled browser where they can't use any other functionality. We get around this by using setTimeout. SetTimeout is special because it gives us the capability of setting a function call up asynchronously. So in essence, we split the initial function call off from the main load and it takes on synchronous function calls from then on using SyJAX. This frees the user from having to wait for the function call trail to end and allows them to use the web site in other areas.
Effectively we have a asynchronous call to a synchronous function trail, instead of a synchronous call to an asynchronous function trail. I'm sure I will find additional problems with the solution as I use it more and more, but having this option definately alleviates some problems I have been faced with.
Brett Garrison
Steel
Forgot to mention, but this feature will be built into Steel as a means for server function calls to occur from within javascript functions, which allows for true client to server communication... without the hassles of Sending a request, waiting for the response, parsing the response, dumping the parsed result into a variable and calling a totally separate function to handle the result. Steel completely avoids all that shit.
Damnit, I forgot something else. SyJAX is AJAX like I mentioned, and to instantiate a SyJAX request, do something like this:
request.open('GET', url, false);
"false" is what changes it to synchronous. Then do the following:
request.send(null);
It is at this point that makes the difference. AJAX would have passed this point immediately, but SyJAX waits at this point until the response is retrieved. When we get the response, all we have to do is apply it to a variable, and we're done, no problem!
response = request.responseText;
There's no checking for status codes, or ready states, we just assign the response and that's it.
So, it's a response handler ? Why don't you poll for a responses from the application? At n seconds check for a response. Let's you move around in the app while you are doing other stuff. You would have to build a notification listener and a broadcaster. If the person left the site you handle that with the a session time out.