If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

First of all it is a good effort from your side (it always very difficult to write tutorials/articles/books in my opinion), thanks a lot for the ajax introduction.

There are some points I want to point out about the tutorial.

1. If a novice developer tries to get a overview of Ajax this will not provide that perfectly (unfortunate)

2. It is because you've omiited any reference to the server-side processing at all. A novice might be thinking what really happens in the server-side when it invokes the page via ajax function call. You could've extended your example a bit so that it gives an idea about the page's server-side processing from which it gets the data.

1. If a novice developer tries to get a overview of Ajax this will not provide that perfectly (unfortunate)
2. It is because you've omiited any reference to the server-side processing at all. A novice might be thinking what really happens in the server-side when it invokes the page via ajax function call. You could've extended your example a bit so that it gives an idea about the page's server-side processing from which it gets the data.

This allows IE 7 to follow the window.ActiveXObject path locally while using the more efficient window.XMLHttpRequest live. I did this because IE 7 will try to follow the window.XMLHttpRequest path locally, but cannot, due to security restrictions. At least that's a problem in IE 7 with the DD scripts that use a similar type of request test scheme, and I saw no reason why it wouldn't be here, although I might be mistaken.

Notwithstanding this issue about mime-type overrides (I will research that later, but it seems to me that writing code for public release, it might be prudent to include rather than exclude it), I have 'sexed up' my code using yours (mwinter's) as a guide. This is for use in a lightbox 'clone' I've been working on (working title 'mybox') that will not rely on external libraries and should be much leaner code wise, while supporting use of on-page content that degrades well for non-javascript enabled browsers, as well as, optionally, Ajax fetched content and an iframe method that will be Flash friendly (presented here as its part in the mybox object):

Notwithstanding this issue about mime-type overrides (I will research that later, but it seems to me that writing code for public release, it might be prudent to include rather than exclude it), ...

I would prefer to explain the situation properly and let the author investigate what happens in their case. After all, overriding the media type isn't really a fix, but rather a stop-gap measure that may not help in all cases: when the method isn't supported.

No special software is necessary for checking this type of server behaviour: AJAX itself will do.

OK, I'm trying to get this about as right as I can while still keeping the code down. 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. I would be glad to be wrong about this. However, since we don't really need to worry about overrideMimeType() being available because we are testing for its existence before we invoke it, I see no problem with just going ahead and using it. I did take to heart what you said about it making no sense to override to text/xml if text/html is what is wanted though. I had been getting some errors in FF that could only be eliminated by using self closing tags on the requested page. By changing the override to text/html, these errors went away.

Also, I had missed the first time through how you were saying that having an alert and returning false in the case where the request object couldn't be constructed didn't make too much sense in actual use. Since my code is in response to a "return get this.href" sort of onclick event, I have now chosen to return true if the request cannot be constructed. This will result in the link firing normally, loading the page if it is there and giving the server's error page for the event if the page is unavailable. If all goes well, I now return false, so that, since we now have the page as content on the 'top' page, the link will not fire.

Finally, I tried to adhere to the order in which you recommended things be carried out/invoked. Here's the new set up:

I'm still not clear on what the alternatives for testing only for a 200 response would be and what their implications for branching might afford, especially at that juncture in the code. However, it seems to me that if the page is missing at that point, having:

Loading . . .

just sit there until dismissed by the user (they can do that in my script), might not be so bad.