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: <3169925.qSn82auLOT@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Fri, 05 Jul 2013 20:18:29 +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> <1650600.4TcKdCVReu@PointedEars.de> <5caf189e-ea6b-4fd3-9150-84fe9ccf68fd@googlegroups.com> MIME-Version: 1.0 Lines: 104 NNTP-Posting-Date: 05 Jul 2013 20:18:34 CEST NNTP-Posting-Host: fb79d65b.newsspool4.arcor-online.net X-Trace: DXC=Z\MRl16_FV[@@RW1FjIB5S4IUK Thomas 'PointedEars' wrote: >> Well, you have probably nothing important to say anyway, >> let alone something correct. > > It is wise to first read and then conclude. Not the other way around. Pot, kettle, black. >> 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. > > Yes, there is. Reusing an XHR-object is simply not a reliable technology. Utter nonsense. Also, the word you were looking for is “technique”. > Google 'reuse xhr object' gives a good overview of the involved issues and > bugs, especially in MSIE. [Considering your ongoing anti-social address munging, in violation of Internet standards, Netiquette, and Acceptable Use Policy of your service provider, you do not deserve this answer. But it may be of help to other people.] It is typical for you as a wannabe that you cannot provide any *explicit* references or a solid implementation of an algorithm to back up your opinion. All you can provide is hearsay and, at best, mystical incantations of source code. I have tested this approach and JSX:http.js to work in MSHTML/IE from version 6 on, of course. Including in a production environment on a commercial Web site. The mistake that people repeatedly make with XHR, and that Eric Pascarello, the co-author of “Ajax In Action”, first made [1] (among several others that remain unmentioned on the Net to date), and that he corrected later [2], is that they are assigning the event listeners *before* they call open() when it has to be the other way around per Microsoft's very own documentation [3] (and they invented this technique). Stupid mistakes like this, made by people who, getting overconfident by early success, prematurely deem themselves experts, distributed by them among their fellow beginners [4] by selling provably bad books, have lead to many common misconceptions, and are actually *causing* more problems with the application of ECMAScript implementations than they are claiming to solve. In this case, the misconception that you have acquired: that it would not be safe to reuse XHR objects once they are in status “DONE”, and to rely on the built-in event listeners. As a result, so-called “Ajax libraries”, and websites using them, either eat heap memory like candy, or resort to error- prone, comparably CPU-loading setTimeout() workarounds such as you have suggested – needlessly. [1] [2] [3] [4] >>>> [...] 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. > > Ridiculous. See Google-search on 'variable reuse'. All advisories are > clear: don't reuse variables! They must have been written by the same people from whom you draw your “knowledge”. -- PointedEars Twitter: @PointedEars2 Please do not Cc: me. / Bitte keine Kopien per E-Mail.