I agree that asynchronous is the way to go...except in those rare cases when synchronous makes more sense. As a case in point:
You have a tree where the nodes represent entities in a database. As users move/copy/add/delete nodes, the database and tree must be kept in sync. The nodes must be uniquely tied to entities in the DB by some primary key attribute (a unique DB id). So, you can't add or copy nodes on the tree until you get a response back from the server with the id of the newly created entity.
While you can (as was implied in an earlier post), ignore what happens on the server, would a user be happier if the application became out of sync with the database when the whole point is to manipulate the database?
Here is an example of where synchronous calls are needed.
I have a app where a user is selecting multiple people displayed in a grid, they are supplying subject and message for an email. The email needs to be sent to everyone selected from the list.
What I would like to do is have a progress bar update each time a message is sent until they are all completed.
Then update the history grid in the south region.
With async call it will just run all of the email requests at the same time and there is no user updating going on until the requests are all complete.
As for the AJAX as an acronym and that's what it means fanatics, the AJAX idea is intended to stop the repetitive refreshing of the entire browser page and opens our web apps up to performing the way native client apps have in the past.
Oh, and XML is also in that acronym. So, with that in mind you are no longer allowed to use json to transfer data sets.
What I would like to do is have a progress bar update each time a message is sent until they are all completed.
Then update the history grid in the south region.
With async call it will just run all of the email requests at the same time and there is no user updating going on until the requests are all complete.
@hosehead - I believe you have that backwards. If you have constructed a synchronous sample that does what you want, you'd probably notice that the progress bar does few (if at all) updates until the entire 'unit of work' is done. A synchronous call would block further script execution until you server actually returned something. Yet another case for async.
If you are executing each sendmail async, then the user would not have to wait for a busy mail server to respond to success or failure. Ext has a rich event system that would handle all that for you without the need for browser lockup.
aye,
with both async and sync the progress bar does seem to update all at once after everything is done. I think I have that fixed up for sync now though.
I would agree with doing an async request and just letting the user know when it had completed if this application had other uses. However, this app has one goal in life and that is to send those emails. And the users want to watch them go. I love me some async, use the hell out of it. But in this, and a hand full of other cases, you just gotta have sync. It should definitely be used only when you absolutely have to though.
there is also the possibility that I have completely missed something and there is some way to make the app what I need to do without using sync calls.
yep, what your suffering from is: poor Browser refresh rates (sync/async is not primary issue). If you look at this thread regarding a loadmask extension, you'll see the benefit of what defer has to offer. Try to apply that concept to your problem (and switch back to asynch). Should smooth things out a bit.
didn't read D's answer until after I had found a nice fix, but as usual I was just plain wrong.
I now have everything working the way I had intended it to work using Async calls.
In this code I am switching divs around, and due to a circumstance I need to replace one div, before setting up other stuff. So as you can see I have a contacts.callAjax inside a request. This is one time I desperately need syn over async.
And if anyone can see a better method I am all for it.
@Cyberangel67 - It's not clear (to me anyway) what the dependencies are based on your last post.
Are the last three div's going to be children of the, possibly undefined, first one?
Just as a thought, how have people got round using a synchronous request when using a window unload or beforeunload event? Useful for saving state for a page, for example. With an asynchronous call the callback function gets destroyed before it can be executed. In effect, you never know if the async. call has been successful.
as tryanDS said, your approach is fundamentally flawed. If you want to do this, and you want to make sure that all your requests are loaded before the page loads: