Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
The Internet

Asynchronous Requests with JavaScript and Ajax 178

Posted by CmdrTaco from the nothing-else-happening-today dept.
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 discussion has been archived. No new comments can be posted.

Asynchronous Requests with JavaScript and Ajax More

Asynchronous Requests with JavaScript and Ajax

Comments Filter:

  • Hello world (Score:3, Insightful)

    by jcaldwel ( 935913 ) on Sunday January 22, 2006 @12:04PM (#14532823)
    This looks like the same AJAX "Hello World" I have read dozens of times before. Nothing new here.
    • I think the point here is that it's supposed to work cross-browser

      • I didn't even entertain the idea of using it before it was cross browser. Therefore, every one of the dozens of examples are cross-browser.

      • Every ajax 'hello world' example out there is cross browser. That exact same piece of code is reproduced in dozens of articles, perhaps thousands if you want to venture that deeply into Google's search results.

    • Re:Hello world (Score:3, Interesting)

      by KiloByte ( 825081 )
      Actually, I thought they mean a way how to have it truly asynchronous -- ie, without building a whole TCP connection first, getting acks and what not. But no, this is just the very basic XMLHttpRequest.

      So, would anyone be able to tell me how to send something to a server using a single half-trip? It may be a part of a persistent connection, any eventual ack can be sent through a separate channel, I don't really care about bandwidth -- all that matters is the latency between the user's action and the time

      • Re:Hello world (Score:3, Interesting)

        by mrchaotica ( 681592 )
        Quick question for you: If you only need a "half-trip," how could latency possibly matter? Since it's not waiting for a response from the server, there's no way the client could possibly know how long the request took!

        If you throw away a can, does it matter how long it takes to get to the recycling center?

      • try AFLAX? (Score:3, Informative)

        by MORTAR_COMBAT! ( 589963 )
        http://www.aflax.org/ [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.

    • Re:Hello world (Score:3, Insightful)

      by Bogtha ( 906264 )

      You can't be looking very carefully then. Practically all the Ajax tutorials I've seen make beginner mistakes. This one's special because it's actually decent code.

  • ??? Who did it ?

    • Re:And who invented the XMLHttpRequest class ? (Score:1, Informative)

      by Anonymous Coward
      The company that never invents anything [wikipedia.org] did. And have been using it for years before it was hyped as ajax and web 2.0.

      btw. Funny seeing IBM criticizing the people who invented the damn thing in the first place of implementing it differently than others have chosen to reimplement it.

      • I agree -- that bit of the article seemed rather poorly researched.

        But, looking back at the real history, there are a few reasons it didn't attract wider usage several years ago.

        Something like XMLHttpRequest had been on the minds of many people for a few years. While we diddled around about how to do it in a general cross-platform way, Microsoft went ahead and added their idea of how it should work. Unfortunately, it was available in WinIE only, and they wrapped it up in their ActiveX framework, which mos

  • If you like this, try too AJAX Developer's Journal (Score:4, Informative)

    by jg21 ( 677801 ) * on Sunday January 22, 2006 @12:06PM (#14532838)
    If you liked this article then you will surely like AJAX Developer's Journal [ajaxdevelo...ournal.com], just launched digitally/online and replete with how-to articles [ajaxdevelo...ournal.com] and interviews, all freely available. It's edited by Rob Gonda [sys-con.com].
  • 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?

    • Re:IBM articles; Security with Javascript (Score:5, Interesting)

      by masklinn ( 823351 ) <.slashdot.org. .at. .masklinn.net.> on Sunday January 22, 2006 @12:18PM (#14532896)

      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 [hesketh.com] 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).

      • Re:IBM articles; Security with Javascript (Score:5, Insightful)

        by Jasin Natael ( 14968 ) on Sunday January 22, 2006 @01:05PM (#14533132)
        Well, graceful degradation is nice, but...

        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 Natael

        • ... a genuine demand for functionality that it's impossible to expose without full Javascript support ...

          If only this were true ...

          The internal corporate sites I'm used have a pretty good chance of running only with I-stinking-E, using whatever demon-inspired lock-in technologies they are teaching to Microsoft "programmers" these days.

          It really twists my guts in a knot. Then, I smile, and do what I have to to get the job done.

        • I think users who are disabling JavaScript are already doing themselves more harm than good.

          A website should work without JavaScript - that's the whole point of a webstandards based approach to website design. If a site requires JavaScript to provide access to data, it is fundamentally broken.

          Its amusing that AJAX is promoted as a means for making websites more usable, but surely this should not be at the cost of its accessibility?

          Nothing wrong with building AJAX based applications, just make sure y

      • The web 2.0 should be about getting more information, to more people, more quickly. In this regard, AJAX needs the backup suggested by the progressive enhancement [hesketh.com] ideas. Supporting text only browsers means more people can get information, more often, and often more quickly, if a text only mode is implemented with good design and development tools. I suggest that Ruby on Rails allows for quick and easy text only design, easily implemented and tested, which can then be enhanced in subsequent iterations of dev

        • And I'd add that, for all meanings and purposes, the Web (regardless of it's "versioning") is a wonderfully universal medium: thanks to a pair of assistive technologies, it's possible for blind, paralytics, deafs people, ... to access informations in a much easier, much pleasant way.

          These assistive technologies don't always work well with some javascript stuff. Accessibility is important, and the baseline of accessibility is the base text-only medium, without all the bells and whistles but with the conten

    • I work for a company that makes a virtual office web-app. We log some interesting statistics about the end users.

      1% don't use IE, and all have javascript enabled.

      So no, we have not run into the problem with people having javascript disabled.
      • I work for a company that makes a virtual office web-app. We log some interesting statistics about the end users.

        1% don't use IE, and all have javascript enabled.

        So no, we have not run into the problem with people having javascript disabled.

        You left out the most important detail - does your site require IE/Javascript? Because if I heard about your service, here's what I usually do:

        1. Read article, which is usually regurgitated press material
        2. Google for user experiences or reviews
        3. See that your app requi
    • A slightly related user's point of view (though I'm also a developer):
      I am not "forgoing this technology" because of security concerns, I am getting pissed off because of sites that force me to have Javascript enabled when I don't want to:
      Coming from "JS disabled, enabled if needed/useful", I usually have it enabled now but I don't want to.
      Which means that I will likely show up in the logs as a "non IE, but JS enabled => no problem" user (I am referring here to another answer to your post).

      My probl
    • On another note, it seems that the current flavor of the month is Ajax.

      Flavor of the last 6 months, to be more exact.

      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?

      I rolled out some very serious Ajax apps to a large corporate hardware server producing customer, a LOT of executitives running Safari, XP IE, XP
  • 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

    • Yeah. I mean I understand your reluctance to embrace a tech that was able to be accomplished before (though I might suggest that using hidden iframes was a bit less elegant). However, what do we care about hype. I let it roll off me. I like using the XMLHttpRequest object ...and you can get creative in your web apps with it. To be honest, I think most devs just opted for a page reload most of the time before all these libs and such came around. So in terms of "something new"...well it is new in the r

    • It's not about the technology as much as the innovative ways it is being implamented.
    • Although very simples, AJAX represent a very important step: its the first ever functionality that actually allows a web page to function more like a traditional app. But we only took the first steps. It took YEARS for us to realize what the hell an asynchronous request represented, and when we finally did, most of people waited to see it implemented on a more usabe fashion. This is where the multiple libraries enter.

      Here is a nice start: someone already posted this, but here it goes again: http://en.wikip [wikipedia.org]
      • Although very simples, AJAX represent a very important step: its the first ever functionality that actually allows a web page to function more like a traditional app.

        The first ever.... apart from Applets, Flash, ActiveX...

        Now, web 2.0 is not about changing what the web represents, that much is already established. The web 2.0 is about improving usability and response time

        Actually, the term 'web 2.0' is so vague it is meaningless. I am not sure anyone can clearly say what it is about.

  • Yeah, new news indeed (Score:5, Informative)

    by masklinn ( 823351 ) <.slashdot.org. .at. .masklinn.net.> on Sunday January 22, 2006 @12:13PM (#14532874)

    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 [dojotoolkit.org] or Mochikit [mochikit.com] Javascript libraries/toolkits (others exist btw, those are just fairly stable and advanced), which actually:

    • Make that kind of stuff easier
    • Make that kind of stuff more reliable
    • Give great tools/shortcuts for working with javascript
    • Actually work

    Just wondering...

  • Funny title (Score:5, Funny)

    by Jugalator ( 259273 ) on Sunday January 22, 2006 @12:17PM (#14532891) Journal
    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).

    • Re:Funny title (Score:5, Funny)

      by Xugumad ( 39311 ) on Sunday January 22, 2006 @12:28PM (#14532944)
      Ah, so what you're saying is the title should have been "Asynchronous Requests for XML with Javascript and Ajax"? :)
      • Not quite, sounds like the title was written by LISP-kiddie trying incorporate some recursion. Try this instead: 'Asynchronous Requests with Javascript and Asynchronous Requests with Javascript and Asynchronous Requests with Javascript and Asynchronous Requests with Javascript ..."

    • Re:Funny title (Score:2, Insightful)

      by Kjella ( 173770 )
      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).

      Not to mention that it doesn't actually deal with XML, so it is not Ajax - it is just Asynchronous Requests with JavaScript. Can you say "buzzword applied without understanding or meaning"?

      • Re:Funny title (Score:2, Funny)

        by volve ( 592475 )
        Next you'll be saying that there's no such thing as an "ATM Machine" or a "PIN Number". The's unpossible!

        Damn commies.

        -volve
    • Maybe it's a "Gnu is Not Unix" infinite recursion acronym kind of joke...
  • Isn't it: 'AJAX: Asynchronous Requests for XML (and other things) from JavaScript'?

    Seriously, Sunday's a slow news day and chance for a slower-paced review, but this acronym was thrown around all last year - it's a bit late for a one-liner from some anonymous who doesn't even understand what he's talking about...
  • that you may as well go with a library like CPaint http://cpaint.booleansystems.com/ [booleansystems.com] . It saves a lot of time, and the principle of AJAX is so simple anyway you aren't really missing out on any 'under the hood' shananigans. CPaint combined with some of the JavaScript from Scriptaculous http://script.aculo.us/ [aculo.us] means you can quickly knock up something impressive and responsive with a pretty user interface that will let you extort as much money as you like from any Venture Capitalist you can garner an appointm

  • What to do with XML results? (Score:5, Informative)

    by ccady ( 569355 ) on Sunday January 22, 2006 @12:24PM (#14532923) Journal

    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 [sourceforge.net].

    I challenge someone to come up with a good article on that!

    • Sarissa tutorial (Score:3, Informative)

      by Spy der Mann ( 805235 )
      There ya go [yourhtmlsource.com] :)

    • Re:What to do with XML results? (Score:5, Insightful)

      by bahwi ( 43111 ) on Sunday January 22, 2006 @02:34PM (#14533629)
      Use AJAX without the X. JSON [json.org] works quite well when XML is overkill. Sometimes you will need the complexity of XML, but much of the time(including those examples in that article), XML is complete overkill.

    • It's not covered in many Ajax tutorials because manipulating XML with the DOM is the same as manipulating HTML with the DOM. Any DOM tutorial will suffice.

    • And there are a lot of little gotchas too. For instance with IE version: non-HTTP requests (e.g. file:// protocol) do not set request.status to 200. There are also situations where XML isn't converted in to XML (file:// or ftp:// [ftp] protocol, or when the server's Content-Type is set incorrectly) - this has to be detected and the response text assigned to a separate XMLDOMDocument for parsing. I think only IE can create XMLDOMDocuments as well - other browsers only provide from the XMLHTTPRequest object.

  • Easier than the article (Score:5, Informative)

    by esconsult1 ( 203878 ) on Sunday January 22, 2006 @12:26PM (#14532936) Homepage Journal
    Just use the excellent prototype [conio.net] javascript library instead. Saves a ton of time. It's cross platform, dev language agnostic, and has super sweet functionality built in.

    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 [rubyonrails.com] and its PHP analogue CAKE [cakephp.org], and also the excellent perl framework Catalyst [perl.org]

  • Ajax is around for quite some time and has been reported as one of 15 important tech concepts that might rule 2006 [slashdot.org]. Google has demostrated how to use Ajax and so on.

    I sincerely want to understand if there are any pitfalls. Is Ajax win-win for all of us? are there any security or any other concerns? What could be an argument against Ajax?

    TIA for your answers.

    • - it's not very ADA complient

      - it doesn't work the way the web is designed, as page->page->page, which can create problems. You can't page-page

      - you have to be very careful if you ajax app is making changes to the DB, not just reading

      - 'win-win' doesn't really fit. It's another tool, and like any tool it can be used in the wrong place. The risk is that as 'the' thing, it's going to be used everywhere, even a lot of places where it really doesn't make sense. Kind of like companies putting dumb Flas
      • I wish I had mod points for this. I'm a big proponent of the right tool for the right job, and Ajax isn't always the right tool, especially considering the parent's points.

      • it's not very ADA complient

        Ajax is as accessible as any other form of Javascript - it's accessible if done properly, but there's a lot of people who either don't bother or don't know how.

        it doesn't work the way the web is designed, as page->page->page, which can create problems.

        The way the web is designed is precisely what causes one of the problems that Ajax solves. There are many tasks for which going from one page to another simply doesn't make sense. If I have a list of things and

        • Ajax is as accessible as any other form of Javascript

          True- perhaps it's just a new level of required understanding. Most of the web still hasn't caught up with really making things ADA. The people who make Web 1.0 sites ADA will probably make Web 2.0 sites complient as well- at least in as much as it makes sense. It doesn't make a lot of sense for google maps.

          I recently saw a page that had a graphic with the company contact info in it (address, phone etc) and the alt tag was "Company Contact Info Image".
  • If you're just communicating with other parts of your app instead of 3rd-party components, why use XML? Append a script tag to the document, using the DOM. Put as many GET request variables in the src attribute's URI as you need. Return JavaScript code from the server. Array initializers, object initializers, whatever. You can even put an onload handler on the script tag so you can execute code once the request has completed. This is what I do. There is reason to continually generate and parse XML he
    • If you're just communicating with other parts of your app instead of 3rd-party components, why use XML?
      Because you hope that you're not just developing a piece of disposable dot-com fluff, but something that will be maintained and extended, that will become useful as part of new projects, and maybe even to third parties?
      • In 5 years the technology will have moved on, all software is disposable.
        • In 5 years the technology will have moved on, all software is disposable.
          Sorry, but one of the very first things I did with 'asynchronous messaging and Java' (in 97 back before we got around to making up stupid acronyms) was interface with old VMS systems. Software developers might move on, but very often their software stays around (a lot longer than it was originally designed/expected to)...
      • 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
        • No, I was saying the opposite - the difference that service-oriented architectures are making (over the component-based stuff I used to do in the Industry) is that people making these kind of apps can become service providers so much more easily. I.e. not that you'll want to integrate 3rd party components, but that if you write a nice web-app, people will want to use your underlying services within their own apps. Tell me I'm being naive and academic, but this is definitely the case with a lot of the firs
          • 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.
            • There aren't too many websites that make sense to act as service providers. Most websites are simply just informational
              Semantic web zealots might say that if something is useful written into a webpage (to be human readable), it's useful to expose it aside from the presentation. There again, they'd probably want you to waste your time, (and 'precious' compute cycles ;), or ontological mark-up, not just XML tags...
    • If you're just communicating with other parts of your app instead of 3rd-party components, why use XML?

      Because XMLhttprequest.open returns a DOM tree object. There's no other reason really.
  • If anyone wants a lightweight, simple, cross-platform AJAX objects they should check this out: http://prototype.conio.net/ [conio.net] The well-written javascript (prototype.js) library is the basis for many innovative opensource AJAX frameworks/libraries including: - Ruby on Rails (built-in support) - http://script.aculo.us/ [aculo.us] - http://openrico.org/ [openrico.org] - http://bennolan.com/behaviour/ [bennolan.com]
  • Waitress: ...or Lobster Thermidor a Crevette with a mornay sauce served in a Provencale manner with shallots and aubergines garnished with truffle pate, brandy and with a fried egg on top and spam.
    Wife: Have you got anything without spam?
    Waitress: Well, there's spam egg sausage and spam, that's not got much spam in it.
  • This is how you use AJAX to create XMLHttpRequest instances.

    The Story: http://namb.la/popular/ [namb.la]

    The Explanation: http://namb.la/popular/tech.html [namb.la]
  • What kind of post is this? All about http request?

    I believe we have finally encountered negative information. Read this and you will know quantitatively less than you did before coming here.
  • A more cross-browser solution is to fall back to pulling content from an IFRAME (either a hidden one already on the page, or, preferrably, one created with the DOM) when XMLHttpRequest is not present (in either Microsoft's browser or others). It's pretty trivial to write a Javascript class that will do this.

    For that matter, the most cross-browser solution is to default to using normal page requests when Javascript is unavailable (by defaulting to those actions and using JS to intercept them in the onclick o

  • overriding the constructor (Score:5, Informative)

    by ydnar ( 946 ) on Sunday January 22, 2006 @01:38PM (#14533322) Homepage
    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
  • Wow. I built a couple of apps back in June of 2005 with basically that same methodology! Thanks IBM and Slashdot! Oh and it was cross browser compatiable as well.

  • Firefox AJAX Debugger (Score:5, Informative)

    by Val314 ( 219766 ) on Sunday January 22, 2006 @02:16PM (#14533539)
    pretty usefull: https://addons.mozilla.org/extensions/moreinfo.php ?id=1843&application=firefox [mozilla.org]

    "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/ 01/firebug.html [mozillazine.org] for the tipp
  • This is the follow up article to the one posted a month or two ago:

    http://developers.slashdot.org/article.pl?sid=05/1 2/11/2327239 [slashdot.org]
  • I find it fascinating how this Ajax buzzword took of almost the instant some new economy web consultant wisecrack coined the term in his blog. The stuff Ajax stands for all had been done before but suddenly everybody acted as if there'd be something new.
    It's even admitted by it's 'creators' that the term Ajax is a buzzword. Being in the business of web conltant wisecracking myself I actually find it very usefull. From now on there is no chance whatsoever customers, clients and partners I talk to will get an
  • From the TIBET(tm) writeup on "AJAX" [technicalpursuit.com]:

    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'

    • When confronted with this reality most developers switch to making synchronous calls (taking advantage of XMLHTTPRequest's truly new feature to "cheat")

      Way before this all was called Ajax I used the following simple method:

      1. Keep a - client side - queue of requests to be made to server.
      2. Whenever the current queue is sent to (and processed at) the server, the client places new requests into the queue.
      3. When the server finished processing (or a timeout occurs) the queue (if not-empty) is flushed to the se

  • * open(): Sets up a new request to a server.
    * send(): Sends a request to a server.
    * abort(): Bails out of the current request.
    * readyState: Provides the current HTML ready state.
    * responseText: The text that the server sends back to respond to a request.

    Don't worry if you don't understand all of this (or any of this for that matter)

    I think everybody understand all of this, if somehow involved with software development.

    This article is useless like 90% of the DeveloperWorks

    • Agreed. From TFA:

      This is where that onreadystatechange property comes into play. This property allows you to specify a callback method. A callback allows the server to (can you guess?) call back into your Web page's code. It gives a degree of control to the server, as well; when the server finishes a request, it looks in the XMLHttpRequest object and specifically at the onreadystatechange property.

      The author of this article obviously doesn't know how XMLHttpRequest works if they think that the remote we

  • Oh my - a slashdot Ajax articele! Oh wait, haven't we dont this before here? I mean, we have already talked about Ajax as a buzzword http://it.slashdot.org/article.pl?sid=05/05/24/15 9 211&from=rss [slashdot.org] as well as State-Of-The-Art Ajax-Office apps http://slashdot.org/article.pl?sid=05/09/29/000223 &from=rss [slashdot.org] we also got into Ajax on server load http://ask.slashdot.org/article.pl?sid=05/12/05/23 39256 [slashdot.org] - now why are we "getting back to basics" and talking about an entry-level IBM Ajax article that has year-
  • Who the hell ever deals with the XMLHttpRequest object long-term over the course of real Ajax development? I simple wrote a few functions to deal with this in my toolkit, or I copy and paste from the last project, and bang, I'm done with XMLHttpRequest. I focus on the XML layer, application level coding, look and feel, database stuff... but I do not spend any real time on the XMLHttpRequest object. WTF is the big deal?
  • A little shameless self-promotion, since no one else is shy about pushing what they think is good :) ...

    Another nice introductory article to AJAX, including a working example webapp of a using AJAX with a Struts-based application:
    http://www.omnytex.com/articles [omnytex.com]

    A more "real-world" example of using AJAX: a Struts-based chat app:
    http://struts.sourceforge.net/ajaxchat [sourceforge.net]

    The AjaxTags component of Java Web Parts, which allows you to add AJAX functions to a page in a purely declarative way using a extremely simple JS

  • Ugh (Score:3, Insightful)

    by kuzb ( 724081 ) on Sunday January 22, 2006 @07:49PM (#14535100)
    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.
  • Ric Romero has started working for IBM now?

  • AJA? (Score:3, Informative)

    by roman_mir ( 125474 ) on Monday January 23, 2006 @12:48AM (#14536449) Homepage Journal
    Before there was a word AJAX, there was a way to do the same thing, and I had to do it too: hidden frames + javascript. It wasn't XML though.

    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","valu e3"],["key4","value4"]] - send this string as response and then in your javascript simply eval it. It will become a 2 dimensional array. If you want, you can unroll the array into a hashmap:
    var arr = eval(strin);
    var map=new Array(arr.length);
    for(var i=0;i<arr.length;i++) {
      map[arr[i][0]]=arr[i][1];
    }
    now you can access values in the map by the associated keys:
    map["key4"] == "value4"

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close