I've writtena test piece of code that uses AJAX. It works just fine in every browser apart from IE (now why am I not surprised!!).
There is a form into which you have to type the correct day of the week and then click "submit". The AJAX is used to check that you have entered the correct day of the week and if so the form is submitted (simple!). The parts of the code are given below. I appreciate that I probably don't need to post everything here, but feel free to do a copy-and-paste and try it out for yourself and see how it doesn't work properly in IE! In IE, what happens is the PHP code is called on the first button click, but subsequent button clicks do nothing - do I need to reset the HTTP object or something like that, given that it is a different class instance in IE as compared to other browsers?
The HTML (filename is "scratch.html"):
Code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8"></meta>
<title>Scratch</title>
<script language="JavaScript" type="text/javascript" src="scratch.js"></script>
</head>
<body>
<form name="myForm" method="POST" action="scratch.php">
<span>What day of the week is it? </span><input name="dayofweek" type="text" />
<input type="button" value="submit" onclick="validate();"/>
</form>
</body>
</html>
The Javascript (filename is "scratch.js"):
Code:
var HTTP;
try {
// Firefox, Opera 8.0+, Safari
HTTP = new XMLHttpRequest();
}
catch (e) {
// Internet Explorer (instrument of the devil).
try {
HTTP = new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e) {
try {
HTTP = new ActiveXObject("Microsoft.XMLHTTP");
}
catch (e) {
alert("Your browser does not support AJAX!");
}
}
}
function validate()
{
HTTP.onreadystatechange = function()
{
if (HTTP.readyState == 4)
{
if (HTTP.responseText == "no")
{
document.myForm.dayofweek.style.border = "1px solid #F00";
document.myForm.dayofweek.style.background = "#FDD";
alert("That's wrong! Please try again.");
}
else if (HTTP.responseText == "yes")
{
document.myForm.submit();
}
}
}
HTTP.open("GET","scratch.php?callfunc=checkdayofweek&dayofweek="+document.myForm.dayofweek.value,true);
HTTP.send(null);
}
yep, there are issues with re-using an xhr object in ie, try putting your xhr object detection into a function, basically just wrap your try block with function
Code:
getXHR(){
var HTTP;
// your existing code
return HTTP;
}
and ditch the global HTTP variable, also create a local instances of the xhr object each time the validate function is called, basically inside validate goes var HTTP = getXHR(); and change HTTP in your onreadystatechange function to the keyword this as calls to the onreadystatechange function are in the context of the XHR object itself
__________________
-Mike
"Want me to precludify him, like some kind of dispatcherator?... Can do!" -Bender
A1ien51 speaks the truth, while it was their idea to begin with they created the ActiveX instantiation method, which was followed shortly by instristic support by mozilla, safari, and opera through the use of the XMLHttpRequest object. IE7 included support for the XMLHttpRequest object as well. The difference here is that microsoft is viewing the object as a "one time use", because it doesn't really make sense to try using the same one twice if you really think about it because the properties (after the request is made) become read-only, reassigning to the object after its data has been populated just didn't make sense to them, so they drop support for reuse. Conversely, the other browsers view an XHR as a car, it can go to a place, come home, go to another place & come home & never have to stop for gas. But given certain situations, this car going on trips to the grocery store might not unload all its groceries at home.... meaning that if you're testing the responseText (maybe responseXML too) property to see if the object is done with it's last request instead of the readyState property (as i've seen some do) you might get the data from a previous request instead of the current one (wouldn't know for sure what situations this may occur under but it's just not a risk i'm personnaly willing to take). The reason for this potential is that we the users of these object aren't 100% certain on (or maybe someone is, but whoever it is.... is not me ) when the data about the last trip is stripped & the data from the last trip is applied (or if there is a stage where the properties have a null or undefined value in between trips (there is btw but when exactly does it get there within the lifecycle)). So, for the sake of sanity & not having to write checks against this type of unintended behavior, it actually makes sense for microsoft to take this route. Think of a person who sets up an async request & sets up an interval to check the responseText property of that object to see if it's done instead of using an onreadystatechange event handler, it's possible that the properties of the object wouldn't be reset until the readyState reaches 1 (just for example), so immediately after the request is made, the timeout detects the data, processes it & never actually gets the data from that request. The next request would return the data from the previous one & so on & so forth which could cause big problems depending on the nature of the information you were requesting. Of course, i'm not certain that actually getting this unintended behavior reliably is possible, not on what platform you could do it, but given the right circumstances (browser that doesn't rebuild the xhr object immediately after a request is made, async request, interval polling for readiness instead of event handling, etc.) it could be bad, hence, better just to create a new object each time, not for ms compat reasons, but for your own piece of mind.
__________________
-Mike
"Want me to precludify him, like some kind of dispatcherator?... Can do!" -Bender
Before you post, read our: 
