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 PeriodicalExecu ter(getIncremen ter, 5);
var ud2 = new PeriodicalExecu ter(getMicrotim e, 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').inn erHTML = req.responseTex t;
}

function showMicrotime(r eq)
{
//put returned Text/XML in the textarea
$('microtime_di v').innerHTML = req.responseTex t;
}

[Richard Cornford]

Ray wrote:

Richard Cornford wrote:

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

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

Richard Cornford wrote:

da*******@gmail .com wrote:
<snip>

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

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?

Richard.

[RobG]

da*******@gmail .com wrote:

Richard Cornford wrote:

da*******@gmail .com wrote:
<snip>

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

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?

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(pro cess) {
setTimeout(func tion() _global[process] = null;}, 1000)
}
function endlessLoop() {
stopProcess(arg uments.callee.n ame);
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.
--
Rob

[Ray]

Richard Cornford wrote:
<snip>

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.

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

>
Richard.

[darwinist]

RobG wrote:

da*******@gmail .com wrote:

Richard Cornford wrote:

da*******@gmail .com wrote:
<snip>
... I forget that they are separate threads ...
>
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?

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(pro cess) {
setTimeout(func tion() _global[process] = null;}, 1000)
}
function endlessLoop() {
stopProcess(arg uments.callee.n ame);
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.

---
http://darwinist.googlepages.com/htmldesktop.html
(A free, open-source web-based IDE, windowing system, and desktop
environment, in 31kB of html and javascript.)

>
--
Rob

[Matt Kruse]

Ray wrote:

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
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Matt Kruse]

Ray wrote:

What's wrong with Prototype?

http://www.javascripttoolbox.com/bes...ces/#prototype

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Ray]

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

Cheers
Ray

Matt Kruse wrote:

Ray wrote:

What's wrong with Prototype?

http://www.javascripttoolbox.com/bes...ces/#prototype

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com