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.
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!
I usually consider that 10% of the users have javascript partially or fully disabled either because they use javascript-less browsers (rare) or because of security issues (corporate environments). The trick there is to develop your web application with the Progressive Enhancements philosophy in mind: build a layered, Javascript/AJAX is merely a client-side behavioural layer added on top of the content layer (pure HTML) and the style layer (CSS), it relies on both but shouldn't be necessary for the application itself to work. It's merely applying the good ol' layers separation on your client-side web pages.
Following the Progressive Enhancements "way" raises the chances that your websites will degrade fairly gracefully when the upper layers are not available (old browser, quirks, ...) without "shutting down" the whole site for the user (or lower the cost/pain of having them degrade gracefully).
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
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?
I think users who are disabling JavaScript are already doing themselves more harm than good. There are some genuinely good dynamic interfaces out there, and compared to the time and bandwidth savings they'll get by using them properly, the time required to install FireFox or a popup/ad blocker is negligible.
At least for intranet and company sites, there's a genuine demand for functionality that it's impossible to expose without full Javascript support. Consider a drag-and-drop interface where customer orders appear on the left-hand side, and the line items can be organized into a grid of dates and production stations (a piece of machinery or a particular set of workers) via drag-and-drop. I have a working AJAX app that does this, but I can't think how such an application would be useful in the absence of JavaScript. It would require literally hundreds of pageloads and a metric ton of typing (remember: No Javascript = No Calendar Picker) to do any meaningful analysis and manipulation, and the very act of using it would destroy the user's workflow/concentration, rendering the application less useful than the scrawled paper notes it replaces.
This is the direction the web is moving. There are a lot of consumer applications that would benefit from taking a more dynamic approach, especially when you combine the intuitiveness of drag and drop with the live feedback made possible by XMLHTTPRequest. I think that coddling to users without JavaScript is holding them back, as well as creating a lot of useless "busy-work" for web designers and developers.
Jasin NataelTrue science means that when you re-evaluate the evidence, you re-evaluate your faith.
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
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