Ever wish you could just simply give a function a line of code (that's always the same) and that function instantly comes back after a specified duration, INCLUDING the original arguments you passed in? Up until now, I didn't have a real quick way of doing this. You would have to use setTimeout and a bit of other ugly tactics to make this happen.
Not today. Instead, use a simple workaround that takes in the function's arguments and creates a setTimeout callback. Here's the line of code you would include in your functions :
... and voila, we've got a simple way of detaching the function call from the main process!
Here is the method to make this happen :
Use this function in areas where you don't want a function process to halt the user (So they can visit other parts of the web site). Also useful in SyJAX requests, where the transaction with the server may take a while.
Also, notice that I call a non-existant object method('ignore.fail') so that I can fail out the current main process. If anyone knows a better way to break the entire function process trail, please let me know.
Not today. Instead, use a simple workaround that takes in the function's arguments and creates a setTimeout callback. Here's the line of code you would include in your functions :
// Include it like this :
function someFunction(string)
{
detach(arguments, 600);
//600 is the milliseconds duration until the function call is processed
alert("someFunction : " + string);
}
//And then just run your code :
someFunction("Hello world");
// and after 600 milliseconds, the alert window will come up from someFunction :
// 'someFunction : Hello world'
... and voila, we've got a simple way of detaching the function call from the main process!
Here is the method to make this happen :
function detach(_arguments, duration)
{
if(typeof(duration) == "undefined")
duration = 0;
if(_arguments[_arguments.length-1] != "detached")
{
var argument_string = "setTimeout(function(){_arguments.callee(";
for(var i = 0; i < _arguments.length; i++)
{
argument_string += "_arguments[" + i + "], ";
}
argument_string += "'detached')}, " + duration + ");";
eval(argument_string);
ignore.fail();
}
}
Use this function in areas where you don't want a function process to halt the user (So they can visit other parts of the web site). Also useful in SyJAX requests, where the transaction with the server may take a while.
Also, notice that I call a non-existant object method('ignore.fail') so that I can fail out the current main process. If anyone knows a better way to break the entire function process trail, please let me know.
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