XMLHttpRequest. onreadystatecha nge Method Not Running

[HugeBob]

Hi All,

I'm having a problem with a web app I'm writing. I have a form for
which I'm going to validate one of the fields. I use AJAX to retrieve
XML containing a list of valid entries. My app works under IE, oddly
enough. But, under Firefox, it seems that the
XMLHttpRequest. onreadystatecha nge method is not being called. The
code follows. I'm using synchronous mode because I'm thinking that I
want that global variable g_groupListXML to contain
xmlHttp.respons eText before ajaxGetGroupUse rListXML( ) returns. Am I
right on this point?

function getXMLHTTPReque stObject( )
{
var xmlHttp = null;
try
{
// Firefox, Opera 8.0+, Safari
xmlHttp = new XMLHttpRequest( );
}
catch (e)
{
// Internet Explorer
try
{
xmlHttp = new ActiveXObject(" Msxml2.XMLHTTP" );
}
catch (e)
{
try
{
xmlHttp = new ActiveXObject(" Microsoft.XMLHT TP");
}
catch (e)
{
alert("Your browser does not support AJAX!");
}
}
}
return xmlHttp;
}
var g_groupListXML = null;

function ajaxGetGroupUse rListXML(url)
{
var xmlHttp = null;
xmlHttp = getXMLHTTPReque stObject( );
xmlHttp.onready statechange = function ()
{
if
(xmlHttp.readyS tate == 4)
{

alert("onreadys tatechange called...");

g_groupListXML = xmlHttp.respons eText;
}
}
xmlHttp.open("G ET", url, false);
xmlHttp.send(nu ll);
}

function getGroupListXML (form)
{
var retval = false;
var xmlDoc = null;
var doc = null;

ajaxGetGroupUse rListXML('XMLPr oducingScript.c fm');

// Parse retrieved XML
if (window.ActiveX Object)
{
doc = new ActiveXObject(" Microsoft.XMLDO M");
doc.async = "false";
doc.loadXML(g_g roupListXML);
}
else
{
var parser = new DOMParser( );
doc = parser.parseFro mString(g_group ListXML, "text/xml");
}

xmlDoc = doc.documentEle ment;
form.fieldx.val ue = trim(form.field x.value);

for (var i = 0; i < xmlDoc.childNod es.length; i++)
{
if (xmlDoc.childNo des[i].childNodes[0].nodeValue.toLo wer( ) ==
form.group_name .value.toLowerC ase())
{
alert('String already used');
retval = true;
break;
}
}
return retval;
}

[Ian Collins]

HugeBob wrote:

Hi All,

I'm having a problem with a web app I'm writing. I have a form for
which I'm going to validate one of the fields. I use AJAX to retrieve
XML containing a list of valid entries. My app works under IE, oddly
enough. But, under Firefox, it seems that the
XMLHttpRequest. onreadystatecha nge method is not being called. The
code follows. I'm using synchronous mode because I'm thinking that I
want that global variable g_groupListXML to contain
xmlHttp.respons eText before ajaxGetGroupUse rListXML( ) returns. Am I
right on this point?

You don't have to bother with onreadystatecha nge if you make a
synchronous request, just use the responseXML/Text.
--
Ian Collins.

[-Lost]

"Ian Collins" <ia******@hotma il.comwrote in message
news:57******** ******@mid.indi vidual.net...

HugeBob wrote:

>Hi All,

I'm having a problem with a web app I'm writing. I have a form for
which I'm going to validate one of the fields. I use AJAX to retrieve
XML containing a list of valid entries. My app works under IE, oddly
enough. But, under Firefox, it seems that the
XMLHttpRequest .onreadystatech ange method is not being called. The
code follows. I'm using synchronous mode because I'm thinking that I
want that global variable g_groupListXML to contain
xmlHttp.respon seText before ajaxGetGroupUse rListXML( ) returns. Am I
right on this point?

You don't have to bother with onreadystatecha nge if you make a
synchronous request, just use the responseXML/Text.

Um, if you have to make synchronous calls you need to rethink your AJAX.

http://ajaxblog.com/archives/2005/05...s-requests-bad for just one example.

-Lost

[Ian Collins]

-Lost wrote:

"Ian Collins" <ia******@hotma il.comwrote in message
news:57******** ******@mid.indi vidual.net...

>>HugeBob wrote:

>>>Hi All,

I'm having a problem with a web app I'm writing. I have a form for
which I'm going to validate one of the fields. I use AJAX to retrieve
XML containing a list of valid entries. My app works under IE, oddly
enough. But, under Firefox, it seems that the
XMLHttpReque st.onreadystate change method is not being called. The
code follows. I'm using synchronous mode because I'm thinking that I
want that global variable g_groupListXML to contain
xmlHttp.resp onseText before ajaxGetGroupUse rListXML( ) returns. Am I
right on this point?

You don't have to bother with onreadystatecha nge if you make a
synchronous request, just use the responseXML/Text.

Um, if you have to make synchronous calls you need to rethink your AJAX.

Not if it's a call to get information required to carry on, loading an
interface description for example.

--
Ian Collins.

[-Lost]

"Ian Collins" <ia******@hotma il.comwrote in message
news:57******** ******@mid.indi vidual.net...

-Lost wrote:

>"Ian Collins" <ia******@hotma il.comwrote in message
news:57******* *******@mid.ind ividual.net...

>>>HugeBob wrote:

Hi All,

I'm having a problem with a web app I'm writing. I have a form for
which I'm going to validate one of the fields. I use AJAX to retrieve
XML containing a list of valid entries. My app works under IE, oddly
enough. But, under Firefox, it seems that the
XMLHttpRequ est.onreadystat echange method is not being called. The
code follows. I'm using synchronous mode because I'm thinking that I
want that global variable g_groupListXML to contain
xmlHttp.res ponseText before ajaxGetGroupUse rListXML( ) returns. Am I
right on this point?
You don't have to bother with onreadystatecha nge if you make a
synchronou s request, just use the responseXML/Text.

Um, if you have to make synchronous calls you need to rethink your AJAX.

Not if it's a call to get information required to carry on, loading an
interface description for example.

Very good point! However, causing the UA to block until that information is retrieved is
erroneous.

You can achieve much more efficient results by using an asynchronous call (I mean, come
on, AJAX). Storing the responseText for example, then displaying it where and if, need
be.

In fact, the responseText is normally only available at a readyState of 4, so... I do not
see the *need* of synchronous calls.

-Lost

[Ian Collins]

-Lost wrote:

"Ian Collins" <ia******@hotma il.comwrote in message
news:57******** ******@mid.indi vidual.net...

>>-Lost wrote:

>>>"Ian Collins" <ia******@hotma il.comwrote in message
news:57***** *********@mid.i ndividual.net.. .

You don't have to bother with onreadystatecha nge if you make a
synchrono us request, just use the responseXML/Text.
Um, if you have to make synchronous calls you need to rethink your AJAX.

Not if it's a call to get information required to carry on, loading an
interface description for example.

Very good point! However, causing the UA to block until that information is retrieved is
erroneous.

You can achieve much more efficient results by using an asynchronous call (I mean, come
on, AJAX). Storing the responseText for example, then displaying it where and if, need
be.

It's a tricky problem if you have to set up some preconditions (such as
building an RPC object from a description file) before the AJAX
functionality on the page can be used. You have three choices:

1) Use a synchronous request.
2) Poll to see if the preconditions have occurred.
3) trap the error if an AJAX call is made before the the preconditions
have occurred.

Which you choose probably depends on the environment, I mainly support
intranet applications, so I can take the easy first option.

--
Ian Collins.

[-Lost]

"Ian Collins" <ia******@hotma il.comwrote in message
news:57******** ******@mid.indi vidual.net...

-Lost wrote:

>"Ian Collins" <ia******@hotma il.comwrote in message
news:57******* *******@mid.ind ividual.net...

>>>-Lost wrote:

"Ian Collins" <ia******@hotma il.comwrote in message
news:57**** **********@mid. individual.net. ..
>
>You don't have to bother with onreadystatecha nge if you make a
>synchronou s request, just use the responseXML/Text.
Um, if you have to make synchronous calls you need to rethink your AJAX.
Not if it's a call to get information required to carry on, loading an
interface description for example.

Very good point! However, causing the UA to block until that information is retrieved
is
erroneous.

You can achieve much more efficient results by using an asynchronous call (I mean, come
on, AJAX). Storing the responseText for example, then displaying it where and if, need
be.

It's a tricky problem if you have to set up some preconditions (such as
building an RPC object from a description file) before the AJAX
functionality on the page can be used. You have three choices:

1) Use a synchronous request.
2) Poll to see if the preconditions have occurred.
3) trap the error if an AJAX call is made before the the preconditions
have occurred.

1. Based on your intranet usage, this is ideal.

2. No need to poll when using asynchronous calls. As the readyState will update you
regardless of async or sync.

3. You can however use e.target.status if the AJAX returns erronous results based upon
the context of theXMLHttpReque st.

Example:

function onError(e)
{
alert(e.target. status);
}
XMLHttpRequest. onerror = onError; // assuming XMLHttpRequest is a valid XHR Object

Which you choose probably depends on the environment, I mainly support
intranet applications, so I can take the easy first option.

Ah hah! So the implementation defines the use!

Even in an intranet application I would be hard-pressed to not use async calls. However,
I have used synchronous calls based on the fact an intranet application should have
instantaneous results.

-Lost

[Richard Maher]

Hi Ian, Lost

"-Lost" <mi*********@co mcast.netwrote in message
news:wN******** *************** *******@comcast .com...

"Ian Collins" <ia******@hotma il.comwrote in message
news:57******** ******@mid.indi vidual.net...

-Lost wrote:

"Ian Collins" <ia******@hotma il.comwrote in message
news:57******** ******@mid.indi vidual.net...

-Lost wrote:

"Ian Collins" <ia******@hotma il.comwrote in message
news:57***** *********@mid.i ndividual.net.. .

You don't have to bother with onreadystatecha nge if you make a
synchrono us request, just use the responseXML/Text.
Um, if you have to make synchronous calls you need to rethink your

AJAX.

>>>

Not if it's a call to get information required to carry on, loading an
interface description for example.
Very good point! However, causing the UA to block until that

information is retrieved

is
erroneous.

You can achieve much more efficient results by using an asynchronous

call (I mean, come

on, AJAX). Storing the responseText for example, then displaying it

where and if, need

be.

It's a tricky problem if you have to set up some preconditions (such as
building an RPC object from a description file) before the AJAX
functionality on the page can be used. You have three choices:

1) Use a synchronous request.
2) Poll to see if the preconditions have occurred.
3) trap the error if an AJAX call is made before the the preconditions
have occurred.

1. Based on your intranet usage, this is ideal.

2. No need to poll when using asynchronous calls. As the readyState will

update you

regardless of async or sync.

3. You can however use e.target.status if the AJAX returns erronous

results based upon

the context of theXMLHttpReque st.

Example:

function onError(e)
{
alert(e.target. status);
}
XMLHttpRequest. onerror = onError; // assuming XMLHttpRequest is a valid

XHR Object

>

Which you choose probably depends on the environment, I mainly support
intranet applications, so I can take the easy first option.

Ah hah! So the implementation defines the use!

Even in an intranet application I would be hard-pressed to not use async

calls. However,

I have used synchronous calls based on the fact an intranet application

should have

instantaneous results.

-Lost

-Lost, you don't seem to mention any downside or additional
processing/infrastructure that needs to occur if in Async mode:-

.. Do we not have to provide a Cancel_Request (From memory, I think the
method is .abort() for the XHR object?) function?

.. If the user chooses to cancel the request does it really only cancel the
client end and leave the server clocking up cpu cycles and i/o for no good
reason, and the user is now free to kick off another dodgy query>

.. If the user has hit the "Confirm transaction" button do we not have to
make sure to disable that button while the async XHR request is in progress
otherwise the user's bank statement could end up with transferred $1000 no
$2000 nope $3000 Doh!

.. Is it not like CPM and if what the XHR (or other more sensible server
request API) has to provide is on the critical path then there's no point
letting the user continue 'cos the only other valid thing left to do is
click over the clock?

.. In most (a lot? at least some?) cases, is "freeing up the event thread for
the Cancel Button" the only valid reason to go Async? (And if you're not
providing a cancel button then surely the options are limited?)

.. I've seen at least one predictive text thingy that is still providing
Select Lists for the first character entered of a surname while the user has
finished typing :-( And then key 2, key 3. . . (But admittedly I'm certainly
not arguing that the user should wait 2secs between keystrokes while a
synchronous request gets the matching list :-)

I suppose my question is, "What is this multi-tasking that you'd have the
user do while they're waiting for a response?"

Cheers Richard Maher

PS. Not being able to close the window (without the "Program is not
responding" crap) is certainly a bummer.

[Ian Collins]

Richard Maher wrote:

>
PS. Not being able to close the window (without the "Program is not
responding" crap) is certainly a bummer.

Which is no different from a "regular" desktop application that's
waiting for a repose to come back from something that has become mute.

--
Ian Collins.

[Richard Maher]

Hi Ian,

Ian Collins wrote:

Which is no different from a "regular" desktop application that's
waiting for a repose to come back from something that has become mute.

I didn't know this was a global desktop issue; so I guess no disadvantage
there then either.

But to be fair to -Lost, surely one big disadvantage of serialized
synchronous requests occurs if/when the opportunity for multiple parallel
requests arises (Struggling for an example this early, but let's say
"Roll-up sales figures from the five regional offices") Given that there are
no/few concurrency and locking issues due to the seperate remote databases,
a near linear improvement in performance can be achieved by using Asynch XHR
and kicking all the request off at once, and then sitting at a barrier until
they all come back.

I personally use Sockets with blocking Sends with a variation on subsequent
Blocking Recvs: - I supply a SetSoTimeout(ms ecs) method so that a lengthy
query may return several zero-byte (my flag to indicate timeout) receives
and then give the event thread enough time to process things, like "cancel"
or "Working. . ." message, before rescheduling (setTimer("read Socket()",0))
another read. Once the result-set has started coming back then I
setSoTimeout(ba ckToNormalXmsec s). [But then XHR won't talk to you until the
entire/complete/unmanagably-large result set has been materialized; so why
would anyone using XHR care about parallelism?]

Anyway, what I'd *really* like to know is "How does XMLHttpRequest work?"
How does it provide this Asynchronous Callback or Up-Call, back to the
browser's page? Is (or can) this mechanism be made generic? If I have a
thread running in a Java Applet, can I manufacture a browser-recognizable
event object and instantiate a browser-side fireEvent() method? What is the
API for this?

Does anyone know the inner workings of XMLHttpRequest, and if so can they
please share that information with us/me?

Cheers Richard Maher