Ajax

[tech_support]

Y'know, if you want really good ajax, (and some good DOM as well) you could use the Prototype Framework.

[jscheuer1]

Y'know, if you want really good ajax, (and some good DOM as well) you could use the Prototype Framework.

Don't you mean, if you want bloated code and a slew of unprotected global variables with short names, use Prototype Framework?

I already stated that I was not using external libraries, and Prototype Framework will not help beginners understand the basics anyway.

[tech_support]

Is The Prototype Framework really that bad?
Some companies do use it...

[jscheuer1]

For a DD type script, yes I think so. It's OK, and in some cases even beneficial, if it is used as part of a coordinated site design and all scripts on the site either use it, don't conflict with it, or act in their own scripting space.

Ideally, for a lib like that to be really worth the bother, all pages on a site that use scripts would have it linked as an external script from a single location on the server to their heads and rely upon it both extensively and wherever and whenever possible.

The reasons for this are the overhead, load time, and bandwidth involved in the lib, its complexity, and vulnerability to conflicts. If it is used in this way, as the primary script that powers all other scripts on a site, this minimizes its drawbacks and maximizes its advantages.

But, for the casual script user, it is overkill at best.

Also, from what I can gather, mootools is a superior lib. This (the choice of libs, if you are using one) is not as critical though, as is making sure to use it as efficiently and thoroughly as possible.

[mwinter]

From what you (mwinter) write, it appears (and testing seemed to bear this out), I would need to create a separate request object and send it just in order to see if the mime type is as expected and that it would then be too late to change the mime type for that request.

This wasn't what I was trying to get at: I was describing the test as something to do during development to determine server behaviour. Based on the results, the developer can either attempt to reconfigure the server or try to fiddle the response with the overrideMimeType method (which I wouldn't recommend).

At production time, the developer should know exactly what the server will do, so no testing is required.

I would also point out that changing the media type of the response is only necessary to have the client properly process an XML response, enabling the responseXML property.

[jscheuer1]

Revisiting this thread after much time because I've learned a few things. Here is a good somewhat advanced routine, that can handle more than one request at a time. It's fairly well commented:

function loadXmlHttp(url, id) {
var f = this;
f.xmlHttp = null;
/*@cc_on @*/ // used here and below, limits try/catch to those IE browsers that both benefit from and support it
/*@if(@_jscript_version >= 5) // prevents errors in old browsers that barf on try/catch & problems in IE if Active X disabled
try {f.ie = window.ActiveXObject}catch(e){f.ie = false;}
@end @*/
if (window.XMLHttpRequest&&!f.ie||/^http/.test(window.location.href))
f.xmlHttp = new XMLHttpRequest(); // Firefox, Opera 8.0+, Safari, others, IE 7+ when live - this is the standard method
else if (/(object)|(function)/.test(typeof createRequest))
f.xmlHttp = createRequest(); // ICEBrowser, perhaps others
else {
f.xmlHttp = null;
 // Internet Explorer 5 to 6, includes IE 7+ when local //
/*@cc_on @*/
/*@if(@_jscript_version >= 5)
try{f.xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");}
catch (e){try{f.xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");}catch(e){f.xmlHttp=null;}}
@end @*/
}
if(f.xmlHttp != null){
f.el = document.getElementById(id);
f.xmlHttp.open("GET",url,true);
f.xmlHttp.onreadystatechange = function(){f.stateChanged();};
f.xmlHttp.send(null);
}
else alert('Your browser does not support AJAX!'); // substitute your desired request object unsupported code here
}


loadXmlHttp.prototype.stateChanged=function () {
if (this.xmlHttp.readyState == 4 && (this.xmlHttp.status == 200 || !/^http/.test(window.location.href)))
	this.el.innerHTML = this.xmlHttp.responseText;
}

Usage:

new loadXmlHttp('requested_url', 'target_element_id')

[Twey]

Commented it may be, but the formatting, I'm afraid, is severely lacking. I think I gave myself a headache trying to read it.

try {f.ie = window.ActiveXObject}catch(e){f.ie = false;}

The statement in the try block is missing a semicolon.

catch (e){try{f.xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");}catch(e){f.xmlHttp=null;}}

This line looks like it lost a fight with Packer — although, strangely, it's one of only a few places where the space-after-control-flow-keyword convention has been observed. Well... once.

 // Internet Explorer 5 to 6, includes IE 7+ when local //

Why is only this comment on a separate line?

if (this.xmlHttp.readyState == 4 && (this.xmlHttp.status == 200 || !/^http/.test(window.location.href)))
	this.el.innerHTML = this.xmlHttp.responseText;

I have to ask: why is this line the only one you've indented in the entire script?

The code itself could do with some work, too. Things like:

var f = this;

Why? And why 'f'?

if (/(object)|(function)/.test(typeof createRequest))

Regular expressions are very expensive. They should be avoided for all but the most complex tasks. Certainly something this simple should not use them. There's also no need to capture — another performance hit.

/*@cc_on @*/

CC has already been turned on earlier in the code — it doesn't magically turn itself off again. Proper formatting* would make it clear that the 'end' applies to the 'if', not to the 'cc_on'.

loadXmlHttp.prototype.stateChanged=function () {
if (this.xmlHttp.readyState == 4 && (this.xmlHttp.status == 200 || !/^http/.test(window.location.href)))
	this.el.innerHTML = this.xmlHttp.responseText;
}

innerHTML is, of course, entirely non-standard, and should be avoided wherever possible. It certainly shouldn't be used without a fallback. HTML is not a good format for data transfer anyway — it's semantic rather than structural, and the chances are that if one is transferring code like this, a lot of semantic or presentational code is being transferred that could more easily be stored in a template on the client-side. The required format for proper client-side rendering is rarely the optimal format for data passing and handling. You're also missing a semicolon after this statement. By making this function so specific, you're making code reüse much harder. If I only want to get an XHR for some other purpose, I can see no way to do it but to copy-and-paste big chunks of the code.

Additionally, why do we check every time a new instance is created? Surely Firefox isn't going to morph into ICEBrowser while we're not looking? I'll admit that I wouldn't put it past IE, but I hardly think we can cater to that possibility.

*

    // used here and below, limits try/catch to those IE browsers that both benefit from and support it
    /*@cc_on @*/

    // prevents errors in old browsers that barf on try/catch & problems in IE if Active X disabled
    /*@if (@_jscript_version >= 5)
        try {
            f.ie = window.ActiveXObject;
        } catch (e) {
            f.ie = false;
        }
    @end @*/

[jscheuer1]

Mostly all good points, Twey. And I suppose I asked for this by referring back to older work of mine (which I still feel is very useful and more complete insofar as it actually goes than most comparable routines of its type in various script libraries).

I especially like what you said about browsers not changing what method that they may use to secure the script's xmlHttp object, not even IE will do this as far as I can imagine, so it would be a performance improvement to only determine this once.

Two of your comments though I would like to explain why I think they're not or may not be correct -

About:

/*@cc_on @*/ // used here and below, limits try/catch to those IE browsers that both benefit from and support it
/*@if(@_jscript_version >= 5) // prevents errors in old browsers that barf on try/catch & problems in IE if Active X disabled

I used that syntax on mwinter's recommendation. It was his view at that time that not all IE browsers that respect @cc will automatically turn it on without the /*@cc_on @*/ coming first. At least that's how I understood his explanation as regards that.

The other thing is innerHTML. Here I have two primary thoughts:

1. For a basic point and shoot AJAX for content into an existing element, it's still very efficient and workable in most cases, and I'm not certain how it could be improved upon without a lot of added code, though the thought just occurred to me that there may be a way to clone the nodes - However, I seem to remember that requiring further testing and branching depending upon browser and being quite a bit more complex than one might first imagine.
   
2. Since this is just the outline of a routine, what you do with the xmlHttp.responseText or other objects/properties of the xmlHttp object is really up to you or whoever uses the code. In other words, just because I used innerHTML in the exemplar is no reason why it must be used.

In fact, I have already modified this routine numerous times for specific applications, some of these modifications make an entirely different use of the result.

[Twey]

I used that syntax on mwinter's recommendation. It was his view at that time that not all IE browsers that respect @cc will automatically turn it on without the /*@cc_on @*/ coming first. At least that's how I understood his explanation as regards that.

That's true — the browser requires this directive to know to process conditional compilation instructions. However, it's a directive completely separate from the @if you're using. Once it's on, it's on, and it doesn't change for the rest of the script. You can put it just once at the beginning of your script, and you'll be fine.

I'm not certain how it could be improved upon without a lot of added code

Don't be afraid of extra code. Javascript comes with notoriously few primitives, but it's a powerful enough language that just about all generic code can be created and stored safely in standalone libraries. As every high-level developer knows, if it's in a library, then it doesn't really exist Some tasks do intrinsically depend on other, separate tasks — for example, it's trivial, given a working parser for each desired image format, to write a procedure to find the colour of a specific pixel, but it would be horribly ugly and really quite difficult to build a semi-complete parser for each format into that procedure, and even worse to build in full, generic versions that nobody else can use.

Since this is just the outline of a routine, what you do with the xmlHttp.responseText or other objects/properties of the xmlHttp object is really up to you or whoever uses the code.

That's all very well for advanced users, and I myself may well use this code or something based on it in place of the minimalist XHR-creating code currently in my libraries, since it seems to support a good deal more old browsers than I usually bother with. Newbies, though, are likely to copy-and-paste verbatim, possibly without even understanding the code. If they do take note of what it's actually doing, then they'll probably look to it as a paradigm of good code, since it's written by an expert like yourself.

[jscheuer1]

So, as far as replacing innerHTML in the exemplar, (keeping beginners in mind) what would you recommend?