Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #20550

Re: Ajax issue

Show key headers only | View raw

Bart Van der Donck <bart@nijlen.com> 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 <bart@nijlen.com> 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] <http://www.w3.org/TR/2012/WD-XMLHttpRequest-20121206/>
 
>>> 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.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Ajax issue saurabh.khemka4@gmail.com - 2013-06-29 07:59 -0700
  Re: Ajax issue JJ <duh@nah.meh> - 2013-06-29 22:07 +0700
  Re: Ajax issue Bart Van der Donck <bart@nijlen.com> - 2013-07-04 00:33 -0700
    Re: Ajax issue Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-07-04 16:26 +0200
      Re: Ajax issue Bart Van der Donck <bart@nijlen.com> - 2013-07-05 01:15 -0700
        Re: Ajax issue Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-07-05 11:38 +0200
          Re: Ajax issue Bart Van der Donck <bart@nijlen.com> - 2013-07-05 07:48 -0700
            Re: Ajax issue Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-07-05 20:18 +0200
      Re: Ajax issue John Harris <niam@jghnorth.org.uk.invalid> - 2013-07-05 15:28 +0100
  Re: Ajax issue Matt Tacchi <mangamatt81@gmail.com> - 2013-07-11 00:34 -0700
    Re: Ajax issue Tim Streater <timstreater@greenbee.net> - 2013-07-11 09:34 +0100

csiph-web