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

Groups > comp.lang.javascript > #20491 > unrolled thread

Ajax issue

Back to article view | Back to comp.lang.javascript

Contents

  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

#20491 — Ajax issue

 I am trying to make 2 ajax calls on a button click in javascript. The response of the first web service will decide whether the second ajax calls should be made or not. When I am trying to call the second web service in the success function of the first one, I am able to get the response but the HTML UI freezes. But if I make a single ajax call and displays its response, it works fine.

[toc] | [next] | [standalone]

#20492

On Sat, 29 Jun 2013 07:59:38 -0700 (PDT), saurabh.khemka4@gmail.com wrote:
>  I am trying to make 2 ajax calls on a button click in javascript. The response of the first web service will decide whether the second ajax calls should be made or not. When I am trying to call the second web service in the success function of the first one, I am able to get the response but the HTML UI freezes. But if I make a single ajax call and displays its response, it works fine.

Definitely the code, whatever it is.

[toc] | [prev] | [next] | [standalone]

#20545

saurabh...@gmail.com wrote:

> I am trying to make 2 ajax calls on a button click in
> javascript. The response of the first web service will
> decide whether the second ajax calls should be made or 
> not. When I am trying to call the second web service 
> in the success function of the first one, I am able to
> get the response but the HTML UI freezes. But if I
> make a single ajax call and displays its response, it 
> works fine. 

Some ideas:
 
1. You're talking about calling [cit.] "the second web service in the success function of the first one". This is not recommended; it is better to cleanly finish the first AJAX-function before proceeding;
 
2. A 'setTimeout()'-function *might* *maybe* help;
 
3. Common 'XMLHttpRequest'-techniques typically use some variables. You would want to make sure that none of those are repeated in the second function, and that their scoping is correct;
 
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.
 
Hope this helps,
 
-- 
Bart

[toc] | [prev] | [next] | [standalone]

#20546

Bart Van der Donck <bart@nijlen.com> wrote:
                    ^^^^^^^^^^^^^^^
Wrong, see RFC 5536 and <http://www.google.com/intl/en/policies/terms/>.

> saurabh...@gmail.com wrote:
>> I am trying to make 2 ajax calls on a button click in
>> javascript. The response of the first web service will
>> decide whether the second ajax calls should be made or
>> not. When I am trying to call the second web service
>> in the success function of the first one, I am able to
>> get the response but the HTML UI freezes. But if I
>> make a single ajax call and displays its response, it
>> works fine.
> 
> Some ideas:
>  
> 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.

> 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.  Using the event listener is the safe approach.
  
> 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.

> 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.
  
> 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.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#20549

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.

>> 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. 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).

>> 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. Take a midsize programming project that uses e.g. 500 variables; would you start reusing those all the time, you end up with a spaghetti of scoping, conditions, resets, etc. Do yourself a favour in the future: use one variable for one thing and give it a clear scope.

>> 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.

>> 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.

-- 
 Bart

[toc] | [prev] | [next] | [standalone]

#20550

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.

[toc] | [prev] | [next] | [standalone]

#20552

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.

> 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. Google 'reuse xhr object' gives a good overview of the involved issues and bugs, especially in MSIE.

>>> [...] 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!

-- 
 Bart

[toc] | [prev] | [next] | [standalone]

#20555

Bart Van der Donck wrote:

> 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] 
<http://wayback.archive.org/web/20080516162853/http://radio.javaranch.com/pascarello/2006/03/30/1143735438047.html>
[2] 
<http://wayback.archive.org/web/20080705122203/http://radio.javaranch.com/pascarello/2006/03/31/1143817890773.html>
[3] <http://msdn.microsoft.com/en-us/library/ie/dd576252(v=vs.85).aspx>
[4] <http://ajaxian.com/archives/the-xmlhttprequest-reuse-dilemma>

>>>> [...] 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.

[toc] | [prev] | [next] | [standalone]

#20551

On Thu, 04 Jul 2013 16:26:39 +0200, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Bart Van der Donck <bart@nijlen.com> wrote:
>                    ^^^^^^^^^^^^^^^
>Wrong, see RFC 5536 and <http://www.google.com/intl/en/policies/terms/>.

  <snip>

That comment is remarkably obscure even by your standards, Thomas.

Explain!

  John

[toc] | [prev] | [next] | [standalone]

#20611

On Saturday, June 29, 2013 3:59:38 PM UTC+1, saurabh...@gmail.com wrote:
> I am trying to make 2 ajax calls on a button click in javascript. The response of the first web service will decide whether the second ajax calls should be made or not. When I am trying to call the second web service in the success function of the first one, I am able to get the response but the HTML UI freezes. But if I make a single ajax call and displays its response, it works fine.

I wouldn't recommended making two AJAX calls in succession of each other like this due to timing issues. As Bart has suggested you could use setTimeout() on the second call, but speaking from experience errors could still occur under the right circumstances. 

I recommend having a re-think about your server side logic so you only need make a single AJAX call. Are you passing variables along with the first request?

[toc] | [prev] | [next] | [standalone]

#20613

In article <7398ba78-890a-4d96-9016-4ed4abbe2159@googlegroups.com>,
 Matt Tacchi <mangamatt81@gmail.com> wrote:

> On Saturday, June 29, 2013 3:59:38 PM UTC+1, saurabh...@gmail.com wrote:
> > I am trying to make 2 ajax calls on a button click in javascript. The 
> > response of the first web service will decide whether the second ajax calls 
> > should be made or not. When I am trying to call the second web service in 
> > the success function of the first one, I am able to get the response but 
> > the HTML UI freezes. But if I make a single ajax call and displays its 
> > response, it works fine.
> 
> I wouldn't recommended making two AJAX calls in succession of each other like 
> this due to timing issues. As Bart has suggested you could use setTimeout() 
> on the second call, but speaking from experience errors could still occur 
> under the right circumstances. 

In my app, I make lots of ajax requests in an asynchronous fashion. In 
fact I have instrumented it and the high water mark for such calls is 16 
- that probably occurs when the app starts up and there is lots to do. 
IOW, there is an instant where I have 16 ajax requests pending and the 
app is waiting for 16 lots of results.

In cases where I need to serialise actions, I do just what the OP is 
trying - make a second call in the callback function of the first. This 
works just fine and has worked in this manner for a number of years,

Perhaps what the OP needs to do is to encapsulate the ajax call and 
handling of the response in a function, make sure that the request 
variable is local to the function, and set it to null once the callback 
function returns.

Something like this:

function ajax (url, data, callbackFunction)
     {

     var  request  = window.XMLHttpRequest ? new XMLHttpRequest () : new 
ActiveXObject ("MSXML2.XMLHTTP.3.0");

     request.open ("post", url, true);

     request.onreadystatechange = function ()
          {

          if  (request.readyState!=4)  return;

          if  (request.status==200 && request.responseText!="")  
callbackFunction (request.responseText);

          request = null;

          };

     request.send (data);

     }


(I've removed error handling and instrumentation for clarity).

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web