Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <1650600.4TcKdCVReu@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Fri, 05 Jul 2013 11:38:27 +0200 User-Agent: KNode/4.10.4 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <1372953269.FrdeS7i7de@PointedEars.de> <3c881e35-a08f-44b9-b514-510ba4023f91@googlegroups.com> MIME-Version: 1.0 Lines: 134 NNTP-Posting-Date: 05 Jul 2013 11:40:56 CEST NNTP-Posting-Host: f8744b4f.newsspool4.arcor-online.net X-Trace: DXC=j9EJnL^TZM>;]cDoEWD6A44IUK]gf>WHZ=D34RII1 X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:20550 Bart Van der Donck wrote: ^^^^^^^^^^^^^^^ Still not fixed. Well, you have probably nothing important to say anyway, let alone something correct. > Thomas 'PointedEars' Lahn wrote: >> Bart Van der Donck wrote: >>> 1. You're talking about calling [cit.] "the second >>> web service in the success function of the first >>> one". This is not recommended; >> >> Wrong. >> >>> it is better to cleanly finish the first AJAX- >>> function before proceeding; >> >> That has happened when the “success function of >> the first one” is called. > > I read it different, especially because of the word "in". Calling [cit.] > "the second web service *in* the success function of the first one" sounds > at least suspicious; maybe the XHR-object is still in use, maybe the > buffer is not empty yet, etc. In short: first properly finish the first, > and then go to the second. What is meant here is with “call the second web service in the *success* function of the first one” can only be, in essence, either var xhr = new XMLHttpRequest(); xhr.open("GET", "http://first.web.service.example", true); xhr.onreadystatechange = function () { if (xhr.readyState == 4 && xhr.status == 200) { xhr.open("GET", "http://second.web.service.example", true); xhr.onreadystatechange = function () { // … }; xhr.send(null); } }; xhr.send(null); or (W3C XMLHttpRequest API [1]): var xhr = new XMLHttpRequest(); xhr.open("GET", "http://first.web.service.example", true); xhr.onload = function () { xhr.open("GET", "http://second.web.service.example", true); xhr.onload = function () { // … }; xhr.send(null); }; xhr.send(null); And there is no harm in that approach. In fact, it is wise to reuse the “xhr” variable and referred object value when possible¹. That is, assuming the request-response handling is all done *asynchronously* as it should be, which I doubt here. See below. _______ ¹ That is a *timing* issue: with .readyState == 4, or .onload, the previous request-response processing is, literally, “DONE”, and the object is available for reuse. [1] >>> 2. A 'setTimeout()'-function *might* *maybe* help; >> >> Wrong. A setTimeout() call will increase the risk >> of a timing problem as you can never know how long >> it takes to receive and process the first response. > > But the response time has nothing to do with it. Yes, it has. > It's only about giving a bit of time to the buffer (esp. in MSIE) in order > to end the current job/s and to continue in a clean way. It's not > guaranteed at all that this will help here; see *might* and *maybe*. But I > do remember cases were it was useful (MSIE, not XHR related). You want to sound authoritative, but in fact you have no clue what you are talking about. “… [give] … time to the buffer … to end the current job […]”? OMG, RTFM. >>> 3. Common 'XMLHttpRequest'-techniques typically >>> use some variables. You would want to make sure >>> that none of those are repeated in the second >>> function, >> >> Wrong. Instead, it is wise to reuse variables >> that are no longer used. > > Absolutely not! You only open the door to all kinds of misunderstandings, > bugs and unnecessary complexity. […] IBTD. > >> and that their scoping is correct; > > > > Correct. A common mistake is to use the same XHR > > object twice, while the response handling for the > > first request with that object is still in > > progress. XHR libraries like JSX:http.js implement > > approaches that prevent that from happening. > > That could very well be the OP's problem indeed. Unlikely. It is much more likely that the “the HTML UI freezes” is caused by synchronous response-request-handling (“false”) that should have been asynchronous (“true”) as that is the main common cause for this condition due to the single-threaded nature of many ECMAScript implementations in Web browsers. >>> 4. Not to say that AJAX is bad, but similar >>> techniques exist which form IMHO certainly a good >>> alternative, such as iframes or server-side logic. >> >> Utter nonsense. > > I'm more interested in an Argumentarium rather than a meaningless > oneliner. Present *your* arguments supporting *your* statements *first*. Just saying something is good, or better than, or bad, or worse than, something else, does not make it so. -- PointedEars Twitter: @PointedEars2 Please do not Cc: me. / Bitte keine Kopien per E-Mail.