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

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

Deregistering an AJAX handler

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

Contents

  Deregistering an AJAX handler groovee@cyberdude.com - 2019-05-01 06:17 -0700
    Re: Deregistering an AJAX handler Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-05-01 16:21 +0200
      Re: Deregistering an AJAX handler groovee@cyberdude.com - 2019-05-01 08:51 -0700
        Re: Deregistering an AJAX handler Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-05-01 19:58 +0200
          Re: Deregistering an AJAX handler "Mark-" <nospam@mapson.xyz> - 2019-05-02 00:56 +0000
      Re: Deregistering an AJAX handler Julio Di Egidio <julio@diegidio.name> - 2019-05-01 09:32 -0700
    Re: Deregistering an AJAX handler Jon Ribbens <jon+usenet@unequivocal.eu> - 2019-05-01 14:26 +0000
      Re: Deregistering an AJAX handler groovee@cyberdude.com - 2019-05-01 08:42 -0700
        Re: Deregistering an AJAX handler Jon Ribbens <jon+usenet@unequivocal.eu> - 2019-05-01 15:50 +0000
          Re: Deregistering an AJAX handler groovee@cyberdude.com - 2019-05-01 08:58 -0700
          Re: Deregistering an AJAX handler Julio Di Egidio <julio@diegidio.name> - 2019-05-01 09:07 -0700
      Re: Deregistering an AJAX handler Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-05-01 20:03 +0200
        Re: Deregistering an AJAX handler Jon Ribbens <jon+usenet@unequivocal.eu> - 2019-05-01 18:25 +0000
          Re: Deregistering an AJAX handler Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-05-02 00:20 +0200
            Re: Deregistering an AJAX handler Jon Ribbens <jon+usenet@unequivocal.eu> - 2019-05-02 10:29 +0000
              Re: Deregistering an AJAX handler Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-05-03 03:58 +0200
    Re: Deregistering an AJAX handler Julio Di Egidio <julio@diegidio.name> - 2019-05-01 08:28 -0700
      Re: Deregistering an AJAX handler groovee@cyberdude.com - 2019-05-01 08:44 -0700
        Re: Deregistering an AJAX handler Julio Di Egidio <julio@diegidio.name> - 2019-05-01 09:01 -0700

#36522 — Deregistering an AJAX handler

OK, so I have code like this, say, for doing an AJAX call:

var request = new XMLHttpRequest();
	request.open("GET", "http://localhost:8080");
	request.onreadystatechange = function() {
            blah blah
}


and then finally:

	request.send(null);


What I want to do, is, after the "send", wait say, 10 secs, and then DEREGISTER THE AJAX HANDLER , ie. have the "request.onreadystatechange" do nothing! Or even, maybe, call a different function than the one that originally was defined,  in the code above.

So it'll be like:

	request.send(null);
        setTimeout(foo(), 10000);


What must "foo" do, please? Is it possible to change the "onreadystatechange" handler to null or something? :) I would like it to simply stop execution at that point, because I will be putting stuff after the "setTimeout" that takes a DIFFERENT course of action.


Thanks for your help :)

[toc] | [next] | [standalone]

#36526

groovee@cyberdude.com wrote:
> OK, so I have code like this, say, for doing an AJAX call:

This is NOT called “AJAX call”.  Probably you have been reading the wrong
books, if any.

> var request = new XMLHttpRequest();
> request.open("GET", "http://localhost:8080");
> request.onreadystatechange = function() {
>   blah blah
> }
> 
> and then finally:

That is NOT "finally", but is executed *before* the code inside the function
whose reference you assigned to “.onreadystatechange”.

> request.send(null);
> 
> What I want to do, is, after the "send", wait say, 10 secs, and then
> DEREGISTER THE AJAX HANDLER , ie. have the "request.onreadystatechange"
> do nothing! Or even, maybe, call a different function than the one that
> originally was defined,  in the code above.
> 
> So it'll be like:
> 
> request.send(null);
> setTimeout(foo(), 10000);

Think about it.  You do NOT want to do that.

What you want to do, because it is safe, is this, perhaps:

  request.onreadystatechange = function () {
    if (request.readyState === 4) {
      request.onreadystatechange = null;
    }

    // …
  };

But this is pointless anyway (since IE/MSHTML 9).

Also, if you are targeting only modern environments, do not bother with
“.onreadystatechange”; use “.onload” and “.onerror” instead.

In the end, a (custom) library or framework should/will do the
decision-making for you.  Example:

<https://github.com/PointedEars/JSX/blob/master/http.js>

> What must "foo" do, please? Is it possible to change the
> "onreadystatechange" handler to null or something? :)

Yes.  RTFM.

> I would like it to simply stop execution at that point, because I will be
> putting stuff after the "setTimeout" that takes a DIFFERENT course of
> action.

You have not thought this through.  With *this* request.open(…) call, it is
NOT like the script engine will wait for the response to be received before
it executes your “setTimeout(…)” (which should be “window.setTimeout(…)”) –
and the other way is deprecated.

Do NOT use Google Groups for posting; it is *buggy* and a major source of
lusers/lamers/crackpots/trolls (therefore filtered out by many [1]).  At the
very least wrap your lines manually (max. 72 characters per line is a good
idea), and "subscribe" to the newsgroup so that you can post using your real
name.


[1] <http://twovoyagers.com/improve-usenet.org/>
-- 
PointedEars

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

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

#36534

On Wednesday, 1 May 2019 19:51:28 UTC+5:30, Thomas 'PointedEars' Lahn  wrote:

> > and then finally:
> 
> That is NOT "finally", but is executed *before* the code inside the function
> whose reference you assigned to “.onreadystatechange”.
> 

Yes, I'm AWARE of that.


> > What must "foo" do, please? Is it possible to change the
> > "onreadystatechange" handler to null or something? :)
> 
> Yes.  RTFM.

Oh damn - THAT was the solution all along! I feel like kicking myself :)


> 
> Do NOT use Google Groups for posting; it is *buggy* and a major source of
> lusers/lamers/crackpots/trolls (therefore filtered out by many [1]).  At the
> very least wrap your lines manually (max. 72 characters per line is a good
> idea), and "subscribe" to the newsgroup so that you can post using your real
> name.

Bro, I NEVER use my real name on the net, because it's a Bad Idea. I don't know if any Usenet servers exist in my part of the world, but in any case, I *like* Google Groups' interface - it's nice and colourful, as opposed to a solely-text based newsreader :)

Thanks for your help, btw.

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

#36540

groovee@cyberdude.com wrote:
> On Wednesday, 1 May 2019 19:51:28 UTC+5:30, Thomas 'PointedEars' Lahn  wrote:
>> Do NOT use Google Groups for posting; it is *buggy* and a major source of
>> lusers/lamers/crackpots/trolls (therefore filtered out by many [1]).  At the
>> very least wrap your lines manually (max. 72 characters per line is a good
>> idea), and "subscribe" to the newsgroup so that you can post using your real
>> name.
> 
> Bro,

I am not your brother.

> I NEVER use my real name on the net, because it's a Bad Idea.

Then I hope for you that you will find someone else to help you next time.

> Thanks for your help, btw.

I regret it already.

-- 
PointedEars

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

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

#36544

Thomas 'PointedEars' Lahn wrote:

> > Thanks for your help, btw.
> 
> I regret it already.

What a dick.

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

#36538

On Wednesday, 1 May 2019 16:21:28 UTC+2, Thomas 'PointedEars' Lahn  wrote:

> Do NOT use Google Groups for posting; it is *buggy* and a major source of
> lusers/lamers/crackpots/trolls (therefore filtered out by many [1]).

Trolls and spammers have stopped using GG long ago, you vile idiot.

And GG is not buggy, on the contrary, it's fine per their spec and goals,
which is the ultimate demise of Usenet...

You fucking highly-functional other retard...

*Plonk*

Julio

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

#36527

On 2019-05-01, groovee@cyberdude.com <groovee@cyberdude.com> wrote:
> OK, so I have code like this, say, for doing an AJAX call:
>
> var request = new XMLHttpRequest();
> 	request.open("GET", "http://localhost:8080");
> 	request.onreadystatechange = function() {
>             blah blah
> }
>
> and then finally:
>
> 	request.send(null);
>
> What I want to do, is, after the "send", wait say, 10 secs, and then
> DEREGISTER THE AJAX HANDLER , ie. have the
> "request.onreadystatechange" do nothing! Or even, maybe, call a
> different function than the one that originally was defined,  in the
> code above.

Something like this perhaps?

  var handler = function () { ... }
  var request = new XMLHttpRequest()
  request.onreadystatechange = function () { if (handler) handler() }
  request.open('GET', 'http://localhost:8080')
  setTimeout(function () { handler = function () { ... } }, 10000)

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

#36531

On Wednesday, 1 May 2019 19:56:16 UTC+5:30, Jon Ribbens  wrote:

> 
> Something like this perhaps?
> 
>   var handler = function () { ... }
>   var request = new XMLHttpRequest()
>   request.onreadystatechange = function () { if (handler) handler() }
>   request.open('GET', 'http://localhost:8080')
>   setTimeout(function () { handler = function () { ... } }, 10000)

This looks VERY cool, but - "handler" seems to be getting executed both ways,.... did you make a mistake or something, somewhere in the code?? 
And what is the "if (handler)" for? Why're you checking to see if it exists?

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

#36533

On 2019-05-01, groovee@cyberdude.com <groovee@cyberdude.com> wrote:
> On Wednesday, 1 May 2019 19:56:16 UTC+5:30, Jon Ribbens  wrote:
>> Something like this perhaps?
>> 
>>   var handler = function () { ... }
>>   var request = new XMLHttpRequest()
>>   request.onreadystatechange = function () { if (handler) handler() }
>>   request.open('GET', 'http://localhost:8080')
>>   setTimeout(function () { handler = function () { ... } }, 10000)
>
> This looks VERY cool, but - "handler" seems to be getting executed
> both ways,.... did you make a mistake or something, somewhere in the
> code?? 

No; handler is only called once, by onreadystatechange. Which actual
function it refers to when it is called depends on whether the
timeout has happened yet.

> And what is the "if (handler)" for? Why're you checking to see if it
> exists?

So you can set handler = null if you want no handler to be called.

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

#36535

On Wednesday, 1 May 2019 21:20:30 UTC+5:30, Jon Ribbens  wrote:

> >> Something like this perhaps?
> >> 
> >>   var handler = function () { ... }
> >>   var request = new XMLHttpRequest()
> >>   request.onreadystatechange = function () { if (handler) handler() }
> >>   request.open('GET', 'http://localhost:8080')
> >>   setTimeout(function () { handler = function () { ... } }, 10000)
> >
> > This looks VERY cool, but - "handler" seems to be getting executed
> > both ways,.... did you make a mistake or something, somewhere in the
> > code?? 
> 
> No; handler is only called once, by onreadystatechange. Which actual
> function it refers to when it is called depends on whether the
> timeout has happened yet.


Aaaaah OK, you mean that the "function () {     }" in the "setTimeout" line will have the code for the "DIFFERENT course of action"?? OK, OK, got ya. For some reason, I thought that the "var handler = function ()..." and the setTimeout would have the SAME code - sorry, silly me, I didn't get what you were trying to say :)

That's a REALLY awesome way to do it! :) Thanks, man! :)

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

#36537

On Wednesday, 1 May 2019 17:50:30 UTC+2, Jon Ribbens  wrote:
> On 2019-05-01, groovee@cyberdude.com <groovee@cyberdude.com> wrote:

> > And what is the "if (handler)" for? Why're you checking to see if it
> > exists?
> 
> So you can set handler = null if you want no handler to be called.

Which is eventually gets you back to a simple flag, just misnamed...

Julio

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

#36541

Jon Ribbens wrote:
>   var handler = function () { ... }
>   var request = new XMLHttpRequest()
>   request.onreadystatechange = function () { if (handler) handler() }>   request.open('GET', 'http://localhost:8080')

This does not work reliably; in the worst case, .open(…) will *reset* the
event-handler property value that was just assigned.  .open(…) must be
called *before* assigning to the event-handler properties.

>   setTimeout(function () { handler = function () { ... } }, 10000)

Such nonsense, it is not even wrong.

-- 
PointedEars

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

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

#36542

On 2019-05-01, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> Jon Ribbens wrote:
>>   var handler = function () { ... }
>>   var request = new XMLHttpRequest()
>>   request.onreadystatechange = function () { if (handler) handler() }>   request.open('GET', 'http://localhost:8080')
>
> This does not work reliably; in the worst case, .open(…) will *reset* the
> event-handler property value that was just assigned.  .open(…) must be
> called *before* assigning to the event-handler properties.

Oh, ok. In general it seems better to set event handlers before
calling the method that will lead to the events being raised, but
I am sure you are right that this old and shonky API has many
imperfections.

>>   setTimeout(function () { handler = function () { ... } }, 10000)
>
> Such nonsense, it is not even wrong.

It's neither nonsense nor wrong.

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

#36543

Jon Ribbens wrote:
> On 2019-05-01, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Jon Ribbens wrote:
>>>   var handler = function () { ... }
>>>   var request = new XMLHttpRequest()
>>>   request.onreadystatechange = function () { if (handler) handler() }
>>>   request.open('GET', 'http://localhost:8080')
>> This does not work reliably; in the worst case, .open(…) will *reset* the
>> event-handler property value that was just assigned.  .open(…) must be
>> called *before* assigning to the event-handler properties.
> 
> Oh, ok. In general it seems better to set event handlers before
> calling the method that will lead to the events being raised, but
> I am sure you are right that this old and shonky API has many
> imperfections.

I do not think that the described behavior is an "imperfection", but by
design; and this API is not old:

<https://xhr.spec.whatwg.org/>

However, it should be noted that in the latest revision of the API (i.e., at
the time of writing) a “readystatechange” event is to be fired as the last
step in the “.open(…)” algorithm.  It is not obvious whether the
event-handler attributes are to be reset as well; however, this indicates
that they are not to be reset, and if so, then assigning to
“.onreadystatechange” before calling “.open(…)” will cause the referenced
function to be called, which is usually not wanted.

That “.open(…)” calls the event listener might be the reason why the OP
wants to reset the latter: they might have assigned to the property before
and have difficulties handling this additional .open(…) call.  However, as I
indicated, doing this with window.setTimeout(…) *outside* the event listener
is conceptually *wrong: It would produce a race condition dependent on the
load of the client and server systems, and the network connection.

>>>   setTimeout(function () { handler = function () { ... } }, 10000)
>>
>> Such nonsense, it is not even wrong.
> 
> It's neither nonsense nor wrong.

It is *most definitely* nonsense because the request is (to be) processed
*asynchronously*.

-- 
PointedEars

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

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

#36545

On 2019-05-01, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> Jon Ribbens wrote:
>> Oh, ok. In general it seems better to set event handlers before
>> calling the method that will lead to the events being raised, but
>> I am sure you are right that this old and shonky API has many
>> imperfections.
>
> I do not think that the described behavior is an "imperfection", but by
> design; and this API is not old:

It's over 20 years old. In web terms that's practically prehistoric.
It pre-dates the existence of IE6!

>>>>   setTimeout(function () { handler = function () { ... } }, 10000)
>>>
>>> Such nonsense, it is not even wrong.
>> 
>> It's neither nonsense nor wrong.
>
> It is *most definitely* nonsense because the request is (to be) processed
> *asynchronously*.

That's a non sequitur.

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

#36551

Jon Ribbens wrote:
> On 2019-05-01, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Jon Ribbens wrote:
>>> Oh, ok. In general it seems better to set event handlers before
>>> calling the method that will lead to the events being raised, but
>>> I am sure you are right that this old and shonky API has many
>>> imperfections.
>>
>> I do not think that the described behavior is an "imperfection", but by
>> design; and this API is not old:
> 
> It's over 20 years old.

No.

> In web terms that's practically prehistoric.
> It pre-dates the existence of IE6!

No.

You are referring to a version of the API that has not been deployed since
about a decade ago.  Progress has been made in the meantime.

>>>>>   setTimeout(function () { handler = function () { ... } }, 10000)
>>>> Such nonsense, it is not even wrong.
>>> It's neither nonsense nor wrong.
>> It is *most definitely* nonsense because the request is (to be) processed
>> *asynchronously*.
> 
> That's a non sequitur.

No.  Learn to read.

-- 
PointedEars

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

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

#36530

On Wednesday, 1 May 2019 15:18:06 UTC+2, gro...@cyberdude.com  wrote:

> What I want to do, is, after the "send", wait say, 10 secs, and then
> DEREGISTER THE AJAX HANDLER

Unset a flag at the beginning: then, when the timeout expires, set the
flag.  Now, back to the handler, first check the flag: if it is set,
don't do anything, otherwise proceed as usual.

(And, if you use closures appropriately, no need to write spaghetti
anything, but never mind: you use tons of global variables already
so let's leave the advanced lessons for another day...)

HTH,

Julio

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

#36532

On Wednesday, 1 May 2019 20:58:35 UTC+5:30, Julio Di Egidio  wrote:

> 
> Unset a flag at the beginning: then, when the timeout expires, set the
> flag.  Now, back to the handler, first check the flag: if it is set,
> don't do anything, otherwise proceed as usual.
> 

I was thinking somewhat along the same lines myself, but Jon Ribbens' solution , above, is better! :)

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

#36536

On Wednesday, 1 May 2019 17:45:08 UTC+2, gro...@cyberdude.com  wrote:
> On Wednesday, 1 May 2019 20:58:35 UTC+5:30, Julio Di Egidio  wrote:
> 
> > Unset a flag at the beginning: then, when the timeout expires, set the
> > flag.  Now, back to the handler, first check the flag: if it is set,
> > don't do anything, otherwise proceed as usual.
> 
> I was thinking somewhat along the same lines myself,

No, on the contrary, you stupid cunt and resident troll,
it's Jon's advice that is along the lines of your initial idea.

> but Jon Ribbens' solution , above, is better! :)

LOL, as you if you could make any such difference...

Indeed, my approach with a control flag is generally better than messing
up with the handler assignment, but that's not a discussion for you.

Indeed no worries, you fucking troll and resident piece of shit,
I am not answering for your benefit...

*Plonk*

Julio

[toc] | [prev] | [standalone]

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

csiph-web