AJAX: Usable Interactivity with Remote Scripting

[ArticleBot]

This is an article discussion thread for discussing the SitePoint article, "AJAX: Usable Interactivity with Remote Scripting"

[Brak]

And not one mention of Prototype? Rico? An article about AJAX without including the immensely helpful AJAX libraries is near a sin.

[AlexW]

Well, it's really an article on 'AJAX usability', rather than everything AJAX.

[andrin]

It´s a nice article but I must object to the use of try/catch. Now try/catch is great but older browsers (if one cares) don´t implement it so their JavaScript interpreter will crash. Why not use old fashioned object detection Cameron?

Very, very nice tutorial!

Printer friendly version of this article is a no show though!

[Sorccu]

I can't believe you're using innerHTML. Sure it's faster to write, but it's definitely NOT the way to go.

[Dean C]

I enjoyed reading this, thanks :)!

[bianster]

Rather than reinventing a thousand wheels, why not consider using the excellent Prototype javascript library. It provides abstraction of lower level details and provides a lot of functionality out of the box.

Unless you're trying to implement another customer library(groan...) this would a great resource, IMHO

EDIT: Oops, didn't see the post by Brak

This is interesting and useful. On accessibility though, while you note not depending on JavaScript, you should be aware that most screen reader users have JavaScript enabled. Accessibility is not about having JS on or off. Screen readers will also have a problem with these forms, as when the new/updated content appears, they will jump to that text, which will thoroughly diorient those users. How you address this I don't know. Ajax sounds interesting and is taking off, but it is opening more accessibility issues, I think. Perhaps people can suggest alternatives that do not involve an alternative site? Any ideas?

[velocd]

Originally Posted by Sorccu

I can't believe you're using innerHTML. Sure it's faster to write, but it's definitely NOT the way to go.

I read this often, the problem is whenever you guys state such a claim you fail to enlighten the reader (without ambiguity) what the alternative is to innerHTML.

Assuming myDiv exists:

innerHTML method

document.getElementById('myDiv').innerHTML = '<span class="largeFont">Hello world!</span>';

DOM method

document.getElementById('myDiv').appendChild(document.createElement('span'));
document.getElementById('myDiv').firstChild.className = 'largeFont';
document.getElementById('myDiv').firstChild.appendChild(document.createTextNode('Hello world!'));

Or more commonly used (when firstChild/lastChild isn't the parent):

var spanElement = document.createElement('span');
spanElement.className = 'largeFont';
document.getElementById('myDiv').appendChild(spanElement);

spanElement.appendChild(document.createTextNode('Hello world!'));

DOM requires you to create a text node, which must have plain text inside. HTML must be added using appendChild() and createElement() then creating the text node inside.

innerHTML is faster, not to mention very easy to use.

It creates all the hierarchical pointers that regular DOM fashions, i.e. using alert(document.getElementById('myDiv').firstChild.firstChild.nodeValue); would print "Hello world!"

So why shouldn't we use innerHTML? Why do hardcore DOM enthusiasts condemn equivocally about it?

I don't fully know, which is why I'm open to interpretation.

For one it's not part of W3C standards, but neither is XmlHttpRequest.

Originally Posted by Brak

And not one mention of Prototype? Rico? An article about AJAX without including the immensely helpful AJAX libraries is near a sin.

Those are some crazy libraries. The syntax in files such as this one is stuff I haven't seen yet in JS. I've known of prototypes and classes, but whoa.

Unfortunately there is a virtually no official documentation on Prototype.. probably why the author of this article didn't consider it so not to confuse the reader.

[Dr Livingston]

> So why shouldn't we use innerHTML?

Because it is not part of the w3c standard, and that is why you shouldn't use it as future browsers may not actually support it's use.

Netscape 6 had it for backward compatibility only, and mozilla followed suit. Use the DOM for obvious reasons I say :)

[Ryan Wray]

Originally Posted by Dr Livingston

Because it is not part of the w3c standard, and that is why you shouldn't use it as future browsers may not actually support it's use.

He actually acknowledged that, and brang up a valid point:

Originally Posted by velocd

For one it's not part of W3C standards, but neither is XmlHttpRequest.

But, on the other hand, it is likely that XmlHttpRequest will be supported by all future browsers; innerHTML will probably not always be supported (as Dr Livingston pointed out). In fact, I was under the impression that if you serve a page as application/xhtml-xml, innerHTML will not work. So, you may find yourself re-writing your scripts if you decide to use this MIME-type (once IE supports it, or before if you're into content negotiation).

[bigduke]

Just yet another how-to article to promote n00b'ism

[Themaninblue]

Hi Guys,

Thanks for the comments.

Just to clear up a few points:

- Although there are a few library implementations of remote scripting technologies, none of them is dominant at this point in time. Additionally, the code needed to get XMLHttpRequest going isn't that complex, so you shouldn't need a large library to have a little feature on your page. Wouldn't you much rather know how to do it yourself, then have the choice of using a library?

- I tried to make the code as simple to follow as possible, hence my use of innerHTML for the completion page. I would normally use standard DOM methods to create HTML elements (such as was done for the error messages), but as that was not the main thrust of the article, I figured for brevity I would forego the long list of elements and text nodes.

- Quite right, if you really care about the < 1% of users who use a browser that doesn't support try/catch, then check for XMLHttpRequest support using if statements:

if (typeof XMLHttpRequest != "undefined")
{
...
}

[McGruff]

An alternative view of Ajax: Listen Kids Ajax is Not Cool

[Sorccu]

Originally Posted by velocd

I read this often, the problem is whenever you guys state such a claim you fail to enlighten the reader (without ambiguity) what the alternative is to innerHTML.

The article being a bit more advanced, I thought that readers would already know how to do it properly. You've got a point, anyway.
(By the way, innerHTML is actually slower in Mozilla.. there were tests about this somewhere.. can't remember where.)

Originally Posted by Themaninblue

- I tried to make the code as simple to follow as possible, hence my use of innerHTML for the completion page. I would normally use standard DOM methods to create HTML elements (such as was done for the error messages), but as that was not the main thrust of the article, I figured for brevity I would forego the long list of elements and text nodes.

I know It's just that using it in articles/blogs/whatever encourages others to do so. Nearly offtopic: And what about XHTML? Don't know about you but it seems a bit illogical to me to be using innerHTML in an xml-compliant document. Time for innerX(HT)ML, eh?

Edit: Oh, I should probably mention this:

The article was very good. Looking forward to more articles from you. In case you're open to suggestions, I'd really like to know more about (XMLHttpRequest &) XPath. A non-feature article would be great, too

It seems simpler to use the onload and onerror events on XMLHttpRequest, rather than the onreadychangestate.

Let me also plug my XMLHttpRequest tracing and debugging scripts (for Firefox), which let you easily see what interactions your page is doing in the background. You can get them from:
http://blog.monstuff.com/archives/000252.html

[redbone]

Originally Posted by Themaninblue

- Although there are a few library implementations of remote scripting technologies, none of them is dominant at this point in time. Additionally, the code needed to get XMLHttpRequest going isn't that complex, so you shouldn't need a large library to have a little feature on your page. Wouldn't you much rather know how to do it yourself, then have the choice of using a library?

I guess one of the advantages of using a library like prototype is that its heavily used in Rapid Development framewords like Ruby on Rails and Perl's Catalyst.

[mutant]

^^ Marcus wrote the "Ajax isn't cool" article:
http://www.lastcraft.com/blog/index.php?p=19

I don't think he could have been more wrong. I believe the points he makes are very weak considering adoption of this technology will strengthen it. Saying something isn't cool because its immature doesn't take a longer view of things.. Marcus had this all wrong.. IMOHO

AJAX is great, but be careful:
http://blogs.xtras.net/mikes/AJAXAPanaceaOrAPendingTrainWreck.aspx

Best AJAX article/example i'v seen so far. Thx.

This was a great article! Going through the parameters, methods and properties and explaining their purpose and values made this read like a condensed SDK for AJAX.

I don't feel that AJAX is a suitable tool for any public sites I will produce. Considering the amount of additional development time invested in writing a seperate process for browsers not supporting the components of AJAX. Now for intranet applications or applications where the environment is controlled then this will be terrific.

if you are generating the xml dynamically on iis using asp3 what is the best approach for sending the content type? would it be best to set a new file extension like .axml and set that to be processed and send the content type as text/xml or would you still have to put the content type into the asp code?

[Themaninblue]

Andy, I'm not too familiar with ASP, but it's definitely safest to send the correct content header, otherwise you won't know exactly how the user's browser is going to parse it at the other end.

[whitehouse]

nice article!

one question I have though:

it only checkes the xml once..
I added some db-code in the request.php, so when a number is given, it returns the name / email address and put's it in the right fields. But when re-enter the receipt-number, it does not change the name/email fields.. so my question : what is the reason that it does not refresh the fields after entering the right receipt-number for the first time ?