14 Sep 2007 8:44 AM #21
As I posted previously, this is availabe for Ext here.
14 Sep 2007 8:56 AM #22
I am a bit disappointed in the Ext folks here. Most of the time calls should be asynchronous, but to purposefully design away the ability to make synchronous calls is naive at best. There are times and situations where asynchronous just will not do, many of which have already been highlighted here.
From the way I see it, it appears that one would have to patch both the Connection.js and all the bindings in order to achieve synchronous requests.
Perhaps you can explain your methodology.
14 Sep 2007 11:43 AM #23
Sure. I'll give this a shot...Perhaps you can explain your methodology.
- A synchronous call blocks the browser's current execution thread until complete.
- There are no timeouts.
[All dry stuff here, but:]
The Ext.data.Connection class was designed with an 'event-model' in mind. That 'event-model' is inherent in every Ext component/widget. That event-model implies asynchonous XHR support for interaction with data sources, because without support for a 'timeout', these components/widgets would 'appear' to lock up during a long-running server response. From a UI perspective that is King! Kudos: Jack !
Ext.lib.Ajax, on the other hand, is the work-horse of the entire AJAX framework. I targeted these enhancements to this area because:
- The 'event-driven' expectations of it's consumers (Ext components/widgets/dataStores and data.Connection) must be preserved.
- The success of an Ajax request throughout the framework is predicated on evaluation of HTTP status codes at the lib.Ajax level. XHR returns a status of (0) for local file systems. Ext, out-of-the-box, considers that a failure. Wanted that/need that to change
- For async calls, Ext uses a poll-timer to monitor the progress of the call. If it's taking to long, the timeout event trickles up the chain to event subscribers. data.Connection (an abstraction layer) could care less about these timers, as its event model simply responds to the few events that lib.Ajax generates. For synchronous support, there is no need for such timers because they won't run because the browser context is blocked. You finally get a response when the browser gives up. Again, IMO data.Connection was/is not the proper place for these mods.
- IE7 (as you may know) introduced it's own native (vs ActiveX) XHR API, and it's own set of problems (not addressing all those here ). The override also gives you a choice of which implementation to use.
- The XHR open, send methods are wrapped (and raise appropriate exceptions) when the browser barks about security and other issues. The response object status is enriched to indicate what the problem was -- didn't have that before.
- It also adds UserId and password auth support for XHR.
So, yes, it may appear that the structure of localXHR.js (and the naming convention is likely ambiguous) was based on 'after-thought'. I assure all who use it -- it was not. It was re-factored to account for the issues mentioned earlier and more.
That said, two no, three design consideration stands out from all others:
1) Preserve Ext components/widgets thirst for events, whether async or sync. That's why the event model still works regardless.
2) data.Connection is not part of the Core, it's a package (you'll likely want to load later ).
3) data.Connection gets sub-classed a lot. lib.Ajax is core, so all components benefit.
The last example on this thread uses the event-based approach (even though the requests are made synchronously) to demonstrate that you can stick with UI-events in your App even though you are blocking the browser every time you do so.
Keep in mind -- for a synchronous request, the response object is also returned immediately by the call to lib.Ajax.request() upon completion (which means it's also returned to data.Connection if you want to deal with it on that level).
So, for all you synchronous-js-loader-wannebees, this is now possible:
Footnote: There are a few Asynch design patterns that would accomplish the same thing, but that's another story -- and much debate.
I'll bow out on that one though.
Last edited by hendricd; 16 Sep 2007 at 4:34 AM. Reason: Replaced Example with ux version that actually works!
15 Sep 2007 11:51 AM #24
The previous post now includes a fully functional js module loader.
I'll be ux.packaging it up and expanding docs on it soon.
1 Oct 2007 7:09 AM #25
Cheers.Necessity is the Mother of invention
1 Oct 2007 7:29 AM #26
Here's his original essay:
Defining Ajax... "asynchronous data retrieval using XMLHttpRequest;"
If you read the article, he specifically contrasts the classic synchronous model with the new Ajax asynchronous model.
2 Oct 2007 7:16 AM #27
I feel you jumped too quickly on this, I was not arguing about the asynchronous side of the story but rather the fact Ajax was originally not an acronym but simply a name for a set of technologies coming together.. I am an old fox who likes to call things in the right way
Cheers.Necessity is the Mother of invention
2 Oct 2007 7:27 AM #28
I was just playing devil's advocate. The context of this thread is a debate on whether or not synchronous calls are useful in Ajax, so I read your post in that light.
3 Oct 2007 12:13 PM #29
3 Oct 2007 12:48 PM #30
95% of the time you would be correct; but a framework as well designed as Ext should provide some form of synchronous access for the other 5%. It can be undocumented, a bit out of the way, anything to keep people who don't know any better from using it. However, it should exist.
Thread Participants: 27
- Animal (3 Posts)
- tryanDLS (1 Post)
- jakeonthenet (1 Post)
- ambience (2 Posts)
- jclawson (1 Post)
- Nullity (1 Post)
- cchiriac (2 Posts)
- hosehead (3 Posts)
- MaxT (1 Post)
- nbinder (1 Post)
- cwolves (2 Posts)
- danielv (1 Post)
- krycek (1 Post)
- Sunflower (1 Post)
- fermo111 (1 Post)
- Cyberangel67 (1 Post)
- hendricd (8 Posts)
- shadun (1 Post)
- pierrot (2 Posts)
- cleonello (1 Post)
- mxu (1 Post)
- mcouillard (1 Post)
- jsaray (1 Post)
- RakeshAdvani (1 Post)
- srinivasan.mohan (1 Post)
- brian.moeskau (3 Posts)
- huskerguy (1 Post)