Issues with IE & Prototype/AJAX

[Steve-O]

The following code works great in FireFox, Opera, Netscape, Safari, and
Gecko, but NOT IE. Why?

I tried using 'native' js with setInterval and setTimeout, but I get
the same result. My IE security settings are not an issue.

Anyone have any insight on this?

Thanks!
-sh
*****************************************************************
// JavaScript Document
var ud1 = new PeriodicalExecuter(getIncrementer, 5);
var ud2 = new PeriodicalExecuter(getMicrotime, 5);

function getIncrementer()
{
var url = 'filter.htm';
var myAjax = new Ajax.Request( url, { method: 'get', onComplete:
showMyData });
}

function getMicrotime()
{
var url = 'filter2.htm';
var myAjax2 = new Ajax.Request( url, { method: 'get', onComplete:
showMicrotime });
}

function showMyData(req)
{
//put returned Text/XML in the textarea
$('my_div').innerHTML = req.responseText;
}

function showMicrotime(req)
{
//put returned Text/XML in the textarea
$('microtime_div').innerHTML = req.responseText;
}

 

[RobG]

The following code works great in FireFox, Opera, Netscape, Safari, and
Gecko, but NOT IE. Why?

For some udisclosed value of 'works' and 'not (works)'.

I tried using 'native' js with setInterval and setTimeout, but I get
the same result. My IE security settings are not an issue.

prototype.js is about 1,800 lines of code and you give no hints as to
where the error might be. Post the 'native' js version and you might
get an answer - or ask in a prototype.js news group or forum.

[...]

 

[darwinist]

The following code works great in FireFox, Opera, Netscape, Safari, and
Gecko, but NOT IE. Why?

I tried using 'native' js with setInterval and setTimeout, but I get
the same result. My IE security settings are not an issue.

Anyone have any insight on this?

Thanks!
-sh
*****************************************************************
// JavaScript Document
var ud1 = new PeriodicalExecuter(getIncrementer, 5);
var ud2 = new PeriodicalExecuter(getMicrotime, 5);

function getIncrementer()
{
var url = 'filter.htm';
var myAjax = new Ajax.Request( url, { method: 'get', onComplete:
showMyData });
}

function getMicrotime()
{
var url = 'filter2.htm';
var myAjax2 = new Ajax.Request( url, { method: 'get', onComplete:
showMicrotime });
}

function showMyData(req)
{
//put returned Text/XML in the textarea
$('my_div').innerHTML = req.responseText;
}

function showMicrotime(req)
{
//put returned Text/XML in the textarea
$('microtime_div').innerHTML = req.responseText;
}

setTimeout sometimes catches me because I forget that they are separate
threads and that they only run once. If you want to make a sort of
do-events style for-loop type structure using setTimeout instead, you
need two functions.

The first starts it going, eg:
<script> setTimeout(code, time); </script>

the second has to decide whether to set it going again:
<script>
DoStuff()
if (keepgoing) setTimeout(code, time);
</script>

careful that you keep track of if the loops is current executing, eg
with a global variable or something more refined. Else someone might
start the timer twice and you'll get two loops that each spawn two new
ones when they finish. Generally doubles the framerate of whatever you
are updating, but not in a good way.

hth

http://darwinist.googlepages.com/htmldesktop.html

 

[Richard Cornford]

... I forget that they are separate threads ...

You should as javascript is not multithreaded, so they are _not_
separate threads.

Richard.

 

[Ray]

You should as javascript is not multithreaded, so they are _not_
separate threads.

When you send an AJAX request using Prototype, isn't it done using a
separate thread? I know what you mean about JS (the language) being not
multithreaded though.

 

[Richard Cornford]

When you send an AJAX request using Prototype, isn't it done using a
separate thread?

I would never use Protoytpe.js, I know javascript. The XML HTTP request
objects (at least when making asynchronous requests) must be operating
in what is effectively a separate thread (but they are likely written
in C++). The handling of the response by javascript is not
multithreaded; no executing javascript in the same environment will be
interrupted by/overlap with the response from and XML HTTP request
object and the handling of that response will not be interrupted
by/overlap with event handling code or setTimeout/Interval triggered
code (the latter must wait until the handling of the XML HTTP response
comes to an end).

I know what you mean about JS (the language) being not
multithreaded though.

Good, VK is likely to try to make out the javascript is multithreaded
(at least he has often done so in the past) but nobody else is that
foolish.

Richard.

 

[Ray]

Richard Cornford wrote:

The handling of the response by javascript is not
multithreaded; no executing javascript in the same environment will be
interrupted by/overlap with the response from and XML HTTP request
object and the handling of that response will not be interrupted
by/overlap with event handling code or setTimeout/Interval triggered
code (the latter must wait until the handling of the XML HTTP response
comes to an end).

Ah, I didn't know this part. Thanks! That's good to know.

<snip>

 

[Ray]

I would never use Protoytpe.js, I know javascript. <snip>

What's wrong with Prototype? What do you think of other libraries like
Dojo toolkit or X ?

Thanks,
Ray

 

[Michael Winter]

What's wrong with Prototype?

There has been at least one thread dedicated to criticism of the
Prototype library[1]. Feel free to browse the archives[2].

What do you think of other libraries like Dojo toolkit or X ?

I'm not trying to speak for Richard, but his answer is highly likely to
be negative; he dislikes monolithic libraries, as do some other regulars
in this group. You will quickly realise that from browsing the
archives[3]. Perhaps he has specific criticism, though.

I've never used any of them, myself, and only glanced at Prototype long
enough to dislike it.

Mike


[1] prototype.js criticism 2006-03-20 07:26:45 GMT
<[email protected]>
<http://groups.google.co.uk/group/co...79c2e?lnk=st&q=&rnum=2&hl=en#5d5110a25cd79c2e>

[2] Google Groups search results for:
group:comp.lang.javascript prototype library wrong | bad | evil
<http://groups.google.co.uk/groups?l...vascript+prototype+library+wrong+|+bad+|+evil>

[3] Google Groups search results for:
group:comp.lang.javascript author:"Richard Cornford" libraries
<http://groups.google.co.uk/groups/s...thor:"Richard+Cornford"+libraries&qt_s=Search>

 

[Ray]

What's wrong with Prototype?

There has been at least one thread dedicated to criticism of the
Prototype library[1]. Feel free to browse the archives[2].

<snip>

Thanks Michael!! That's going to be educational for me

Cheers
Ray

 

[Richard Cornford]

<snip>
What's wrong with Prototype?

It would take too long to explain properly, but it appears to mostly
come down to the authors not really knowing javascript well enough to
appreciate it as a language and instead trying to twist it into
something more like a language that they did appreciate. There is a
Catch 22 in that attitude, in that they would have had to learn to
appreciate javascript before being in a position to do a good job
twisting it to be like their preferred language, at which point they
would no longer have seen a need to make the effort. The inevitable
result of this contradiction is a large collection of interdependent,
brittle, environment limited, inefficient and bulky code.

What do you think of other libraries like
Dojo toolkit or X ?

Libraries are mostly about code re-use, but as a strategy for code
re-use they do not fit well with the nature of browser scripting.
Alternative strategies offer equivalent levels or code re-use (or
better) and are better suited to the necessity of having all the
executable code used downloaded to the browser.

Richard.

 

[darwinist]

You should as javascript is not multithreaded, so they are _not_
separate threads.

What is it then when you fire one or more setTimeout() calls? They
behaves very differently to just continuing with code (other events
will occur, such as a display refresh, for example) and you can have it
fire on user-events, generating multiple timing loops occuring at once.
What is this if not threads?

 

[RobG]

What is it then when you fire one or more setTimeout() calls? They
behaves very differently to just continuing with code (other events
will occur, such as a display refresh, for example) and you can have it
fire on user-events, generating multiple timing loops occuring at once.
What is this if not threads?

A queue.

The browser itself may be multi-threaded and most seem to be - they can
fire many HTTP requests and download various parts of a document
simultaneously. The script element's 'defer' attribute seems to have
been inspired by this behaviour, allowing a browser to download other
resources while downloading and executing the script.

Most browsers will not update the screen while a script is running,
which makes sense - why constantly update the screen while DOM
manipulation is occurring? It makes much more sense to wait until all
modifications have occurred and then re-paint the screen once.

In JavaScript, only one thread runs at a time. It has already been
categorically stated in this thread that one JavaScript process can't
interrupt another, therefore neither setTimeout or setInterval can
interrupt an executing process - they must wait until whatever process
is running completes before they run. Otherwise it would be very
simple to use setTimeout to stop an endless loop, e.g.:

var _gobal = this;
function stopProcess(process) {
setTimeout(function() _global[process] = null;}, 1000)
}
function endlessLoop() {
stopProcess(arguments.callee.name);
while(true){}
}

If the above did work (and I guarantee it doesn't) then stopProcess()
should be able to cancel the endless loop - but it can't because as
long as endlessLoop() runs, no other script will get a look-in. If it
were possible, I imagine it would be used extensively in debugging.

Of course the *browser* may (and some do) provide another thread that
monitors and optionally cancels a an executing JavaScript process, but
that is a host environment thread, not a second (or third or fourth)
JavaScript thread.

 

[Ray]

Richard Cornford wrote:

Libraries are mostly about code re-use, but as a strategy for code
re-use they do not fit well with the nature of browser scripting.
Alternative strategies offer equivalent levels or code re-use (or
better) and are better suited to the necessity of having all the
executable code used downloaded to the browser.

Thanks Richard,

Wondering what the alternative strategies to code reuse are, if not
libraries? The moment you separate your oft-used code into a separate
js file and organize them into functions/classes, you have a library,
don't you?

Regards,
Ray

 

[darwinist]

What is it then when you fire one or more setTimeout() calls? They
behaves very differently to just continuing with code (other events
will occur, such as a display refresh, for example) and you can have it
fire on user-events, generating multiple timing loops occuring at once.
What is this if not threads?

A queue.

The browser itself may be multi-threaded and most seem to be - they can
fire many HTTP requests and download various parts of a document
simultaneously. The script element's 'defer' attribute seems to have
been inspired by this behaviour, allowing a browser to download other
resources while downloading and executing the script.

Most browsers will not update the screen while a script is running,
which makes sense - why constantly update the screen while DOM
manipulation is occurring? It makes much more sense to wait until all
modifications have occurred and then re-paint the screen once.

In JavaScript, only one thread runs at a time. It has already been
categorically stated in this thread that one JavaScript process can't
interrupt another, therefore neither setTimeout or setInterval can
interrupt an executing process - they must wait until whatever process
is running completes before they run. Otherwise it would be very
simple to use setTimeout to stop an endless loop, e.g.:

var _gobal = this;
function stopProcess(process) {
setTimeout(function() _global[process] = null;}, 1000)
}
function endlessLoop() {
stopProcess(arguments.callee.name);
while(true){}
}

If the above did work (and I guarantee it doesn't) then stopProcess()
should be able to cancel the endless loop - but it can't because as
long as endlessLoop() runs, no other script will get a look-in. If it
were possible, I imagine it would be used extensively in debugging.

Of course the *browser* may (and some do) provide another thread that
monitors and optionally cancels a an executing JavaScript process, but
that is a host environment thread, not a second (or third or fourth)
JavaScript thread.

How very interesting. I had to write my own infinite loop examples to
understand what you mean, but see how it distinguishes a queue from the
thread. Thanks for the info.

For many practical purposes, you can have the equivalent of multiple
loops running at once, with the gui still responsive while they're
running, using timeouts.

 

[Matt Kruse]

Wondering what the alternative strategies to code reuse are, if not
libraries? The moment you separate your oft-used code into a separate
js file and organize them into functions/classes, you have a library,
don't you?

Search the google archives of this group for "cornford libraries" and you'll
find many debates on the topic, often with me

 

[Matt Kruse]

What's wrong with Prototype?

http://www.javascripttoolbox.com/bestpractices/#prototype

 

[Ray]

Thanks Matt!! Will do the search you recommended as well.

Cheers
Ray