Slashdot Mirror
Asynchronous Requests with JavaScript and Ajax
An anonymous reader writes "I rarely read an entire article about a single object, especially one that is this simple. However, you will use this object over and over again in each page and application that you write that uses Ajax. This article shows you how to create XMLHttpRequest instances in a cross-browser way, construct and send requests, and respond to the server."
This looks like the same AJAX "Hello World" I have read dozens of times before. Nothing new here.
If you liked this article then you will surely like AJAX Developer's Journal , just launched digitally/online and replete with how-to articles and interviews, all freely available. It's edited by Rob Gonda.
While slightly off-topic, I do have to say that IBM's articles are some of the best on the net. They have very good writers and can explain things without resorting to techno-babble for the layman.
On another note, it seems that the current flavor of the month is Ajax. However, this requires that javascript be enabled. Is anyone running into the problem of finding a lot of users are forgoing this technology because they have (or have been told by their company) to disable javascript for security concerns?
Quality Hosting e3 Servers
I am sorry - i cannot believe how much hype there is over 'ajax'. This is something that has been going on for so long. In the past - we have done this using 1x1 frames and parsed the Xml with light Js libraries. I guess I must be getting old - I always sneered at the 'mainframers' that would complain and say 'that is nothing new - we have been doing that since 1876'. Now - I guess I see the same thing. A new marketing hype name - and the old technique is here
I hope that the next version of the web is much more than HTML pages that don't refresh with a full round trip. Really though - we did this at least 5 or 6 years ago..... I like google maps, Flickr and the others, but it is NOT a revolution. Someone innovate for real and show me a revolution if you want to justify the Ajax hype or the Web 2.0 hype!!!!
-Irate -
Chris
" I have no tag line. "
I mean, the first articles explaining how to create cross-browsers XMLHTTP requests ain't have more than a pair of years anyway...
Wouldn't it be slightly more interresting if Slashdot promoted useful stuff such as the Dojo or Mochikit Javascript libraries/toolkits (others exist btw, those are just fairly stable and advanced), which actually:
Just wondering...
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
OK, here goes some /. nitpicking but it was a funny title: Asynchronous Requests with JavaScript and Ajax. Someone need a reminder of what Ajax is again (Asynchronous JavaScript And XML).
Beware: In C++, your friends can see your privates!
Bah. That's easy. The business of creating and using an XMLHttpRequest is well-documented and easy to do. What is far less well documented is how to access the resulting XML as a cross-browser XML DOM object. (Accessing it as text is easy.)
How does one access the results 1) as an XML DOM, and 2) in a cross browser way. I am currently investigating Sarissa.
I challenge someone to come up with a good article on that!
J'aime mieux les méchants que les imbéciles, parce qu'ils se reposent. -- Alexandre Dumas
I guess you can use JSON, and XML data formats with prototype, but I just use plain old text to accomplish whatever I want.
Prototype is also used in Ruby on Rails and its PHP analogue CAKE, and also the excellent perl framework Catalyst
Newsfollow.com
My honest first impression was that ti was a spyware site, you know, the ones that look useful, but are really just there for the sake of serving ads?
There ya go :)
By all means a pretty site does not mean a good site, there's obviously great content you can find on minimalistic or ass-ugly pages- but is it just me or does for a site preaching the benefits of ajax, it's really disgusting-looking?
space is pretty cool.
Okay, I have to reply, because now you're just rewording part of my statement in lieu of a useful reply.
I just _said_ that the XML isn't useful _unless_ you need/want communication with 3rd-party components that use XML.
Plus, you also seem to be hinting that one should always aspire to connect their app up to 3rd-party components or even that one should always do the work to make the app integratable w/ XML before even knowing that this is necessary or required.
I'm sorry, but this is just another example of wasted programming hours and wasted money spent on the same. If the app does not need it, nobody has asked for it, and suggestions to the contrary are not agreed with, don't build it.
...
With JavaScript, the object that is returned by the newoperator is the return value of the constructor. Which means you can set/override pretty much any object/property with a pseudo-constructor that returns any arbitrary object (class).
Adding XMLHttpRequest to Internet Explorer:
if( typeof window.XMLHttpRequest == "undefined" ) {
window.XMLHttpRequest = function() {
var types = [
"Microsoft.XMLHTTP",
"MSXML2.XMLHTTP.5.0",
"MSXML2.XMLHTTP.4.0",
"MSXML2.XMLHTTP.3.0",
"MSXML2.XMLHTTP"
];
for( var i = 0; i < types.length; i++ ) {
try {
return new ActiveXObject( types[ i ] );
} catch( e ) {}
}
return undefined;
}
}
y
It took me less than 50 milliseconds to realize that site wasn't good... it's full of advertisements and there is little teaching going on. If I visited an AJAX-resource website, I'd like to see some code as soon as possible.
http://www.aflax.org/
poke around in those (excellent) libraries a bit, maybe you'll find more basic socket handling facilities that you are looking for.
maybe "web 3.0" is closer than we think. servers pushing data to web clients.
MORTAR COMBAT!
pretty usefull: https://addons.mozilla.org/extensions/moreinfo.php ?id=1843&application=firefox
/ 01/firebug.html for the tipp
"FireBug is a new tool that aids with debugging Javascript, DHTML, and Ajax. It is like a combination of the Javascript Console, DOM Inspector, and a command line Javascript interpreter."
thanks http://weblogs.mozillazine.org/gerv/archives/2006
This is the follow up article to the one posted a month or two ago:
1 2/11/2327239
http://developers.slashdot.org/article.pl?sid=05/
There aren't too many websites that make sense to act as service providers. Most websites are simply just informational, or shopping carts. I provide our products data to all of the major search engines/shopping sites, but each interface is completely different. This idea of some kind of universal XML has *never* paid off, and I can't imagine it ever will. I agree with the parent poster... it's a lot of waste, both in programming cycles, and machine cycles/bandwidth to add in a layer that is unnecesary.
That being said, I've been using XMLHTTPRequest for many years for some internal stuff. No actual XML anywhere on the site, though. If I did waste my time adding in "XML", my app would be significantly slower.
I don't respond to AC's.
Ironically, the real value in XMLHTTPRequest isn't that communication can be asynchronous. Form submissions, the previous way of handling server communication, were and still are asynchronous. XMLHTTPRequest actually makes it possible to support _synchronous_ calls and provides a single unified way to make either type of call.
Most writings on AJAX would have you believe that's enough -- make an asynchronous call, get an AJAX application. Unfortunately, as anyone who's done much programming with asychronous calls (aka threads) can tell you, making the call is the easy part -- it's coordinating the results that's hard. A simple real world example highlights "the sync problem".
The Sync Problem
Its a common client-side requirement to fetch a template containing static data along with dynamic data from a web service call, blend them into a single UI element, and then display that element in a portion of the user's currently displayed page. In this common case you've got two separate data sources meaning you have two separate calls whose results have to be blended only after both complete. When confronted with this reality most developers switch to making synchronous calls (taking advantage of XMLHTTPRequest's truly new feature to "cheat"). If you decide to hang in there and stay with the asynchronous call format that's great, but we've yet to see a single AJAX toolkit that offers you any kind of multiple-request coordination -- so you'll end up writing the synchronization logic yourself.
If you use TIBET its simple:
Since TIBET was built before you could "cheat" via XMLHTTPRequest it's been designed to support asychronous event coordination from the start. TIBET uses event signaling and a set of types based on the Workflow Management Coalition's petri-net models for workflow event coordination to handle event synchronization. Because it uses events rather than XMLHTTPRequest callbacks you can use the previous example's pattern to join responses from both the server and the user since interactions with the user are asynchronous as well.Seastead this.
I think everybody understand all of this, if somehow involved with software development.
This article is useless like 90% of the DeveloperWorks articles.
If your app requires JavaScript, then clearly, anyone who is logged as using your app WILL have JavaScript enabled.
Your logs won't show how many people wanted to use your app but didn't because they had JS turned off for whatever reason.
retrorocket.o not found, launch anyway?
They lost me as soon as I saw "Web 2.0" in large bold letters. For once, can we keep the marketing BS out of techincal articles? They're like sandpaper down the side of my face.
BeauHD. Worst editor since kdawson.
Just last Friday I had to use AJAX but without XML at work. Instead of XML, it is much easier to just do this:
[["key1","value1"],["key2","value2"],["key3","val
You can't handle the truth.