How to make synchronous AJAX request using Ext library?

[cchiriac]

No argue. For me it was just annoying to have to explicitly code "after you finish this, do that, but only sometimes".
Also I was trying to make a difference between "synchronous" and "asynchronous and sequenced", "asynchronous and grouped" etc.

[nbinder]

Just found this topic and totally disagree.

If your whole application NEEDS to wait for a request in order to continue properly, a syncronous call is the right way. Using an asyncronous one and wait for it to complete, simply doing noops does NOT do it better (remember you need to wait and can't do nothing but showing a "please wait").

Prototype supports syncronous calls, if you are looking for it. It works simply by
asynchronous : false

[krycek]

i agree, something like "asynchronous : false" would be very useful
it would make me save a lot of lines of code
how Prototype do it?

[danielv]

You don't have to trigger the 2nd request from the callback of the 1st unless you need to chain the requests, or stop subsequent requests after a previous failure.

I have a real need for either
a) going synchronous
b) manually blocking until the result of an aync call is available (which is more work than going synchronous and is ideologically equivalent to performing a synchronous call).

We're trying to perform an operation which yields a decision during a drag event in a Tree, in order to determine if the current drag operation was successfully completed. If we go async, I need to block until the results of the AJAX call are returned in order to return the status of the drag.

Perhaps you can suggest an approach which does not involve blocking, and can suspend the remainder of the event handlers until the result of an async call becomes available.

In other words - how do I determine the subsequent handler currently bound to the event i am processing, conditionally over-ride it, and call it with the same parameters it was originally expecting without having to bend over backwards instead of simply making an exceptional use of the *evil* synchronous attribute already built in to the XmlRequest function?

[fermo111]

I agree with the these last posts. Sync/Asynch is a mechanism already built in XHR and it is there so that the programmer can chose what is best for the scenario he is implementing. Sync request have a very respectable name, RPC, and RPC have a long standing tradition. I cast my vote for the full support in Ext.

Luca

[Sunflower]

I agree that getting synchronous calls would be great in Ext (I worked on several 'real time' projects and logic as already explained makes sometimes a lot of sense).

[shadun]

I think that adding a simple param asynchronous: false to the Ext.Ajax.request Config wouldn't be so hard to do. By not adding it you are forcing people to do what the framework wants, not what the user wants the framework to do for him.

Anyway, I still think though that that param is not actually necessary. When I want e.g. to do something after my ajax request finished WITHOUT being able to use the callback function (for whatever reason) I use the Ext.util.Observable as a basis. I simply extend my object in which the call happens with that class, and then I assign an 'onload' handler, which the object fires using the fireEvent method from Observable just as I finish loading and rendering.

Maybe that helps someone.

[Nullity]

See this thread for how to make a synchronous ajax call:

http://extjs.com/forum/showthread.php?p=53192

[hendricd]

See this thread for how to make a synchronous ajax call:

http://extjs.com/forum/showthread.php?p=53192

Nullity,

Based on Ext-base async-only design (by design), your solution leaves 2 underlying timer/pollintervals unused and useless. They aren't even needed when making a sync call as they are blocked until the (current) XHR request is completed.

However, I have added appropriate logic for synchronous calls to the recently posted AJAX override located here.

Cheers.

[ambience]

I know it has been mentioned a couple of times but I would just like to reiterate that synchronous calls have their place. Namely, script dependency loading. Several of my scripts dynamic load components when they are constructed based on configuration information. I am unable to easily convert them to UX components to be shared because I am forced to rely on Prototypes synchronous request support.