• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

XMLHttpRequest

 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I spent most of the day yesterday readig up on XMLHttpRequest, how it works, etc. I even did some small tests with jsp and servlets. But it seems like one of those technologies that doesn't really provide much other than the "Cool" factor. Can anyone list practical reasons to use XmlHttpRequest? What are you using it for? How did it improve upon what you were doing originally?
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've also read up on it but have yet to really kick the tires.

The type of application in which I see this as useful is anywhere a request back to the server must be made but without the desire to repost the whole page.

One type of application in which it could be used is the much-asked-about pattern of updating the options in a drop-down box depending upon the selection of another drop-down.

Another usage could be in a web app such as my BlackBox game implementation. Currently, I make pseudo-asychronous requests back to the server whenever a "play" is made by posting to an invisible iframe and using returned Javascript to manipulate the parent page.

BlackBox could be a good testbed for me to really kick the tires of XmlHttpRequest and see if really offers any advtanges over the child iframe mechanism. One obvious benefit would be in simplifying the client-side window hierarchy by eliminating the iframe and the requisite cross-window communications. What disadvantages it would bring to the table would remain to be seen.
[ April 15, 2005: Message edited by: Bear Bibeault ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bear Bibeault:
One type of application in which it could be used is the much-asked-about pattern of updating the options in a drop-down box depending upon the selection of another drop-down.

Another usage could be in a web app such as my BlackBox game implementation. Currently, I make pseudo-asychronous requests back to the server whenever a "play" is made by posting to an invisible iframe and using returned Javascript to manipulate the parent page.

BlackBox could be a good testbed for me to really kick the tires of XmlHttpRequest and see if really offers any advtanges over the child iframe mechanism. One obvious benefit would be in simplifying the client-side window hierarchy by eliminating the iframe and the requisite cross-window communications. What disadvantages it would bring to the table would remain to be seen.

[ April 15, 2005: Message edited by: Bear Bibeault ]



I've thought of similar situations. The dropdown is a big one. Also, when filling in textfields, querying a database as each letter is typed to get a list of possible phrase completions. Similar to gmail's autocomplete contact when composing a new message.

The problem I have with it, and maybe this is specific to servlets, is it seems to bring things back to the stone age of having to issue a lot of out.write commands are even filling a StringBuffer and then sending that to out.write(). And it adds a ton more Javascript to my code than I used to having to deal with.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

back to the stone age of having to issue a lot of out.write commands



Not sure about that. The way I would envision using this (and I'm not at the point where I know enough to know what is feasible and what is not) is not to try and return HTML, but to return data (perhaps in XML format, perhaps not) that would feed into Javascript routines that perform appropriate actions.

That's pretty much the way BlockBox works now. The response of the iframe-subrequests returns calls to Javascript routines that are already resident in the parent. With XmlHttpRequest I would change things so that the response would return abstracted data that triggers calls to these functions (which is probably how I should have coded BlackBox in the first place).
[ April 15, 2005: Message edited by: Bear Bibeault ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, XML would be the way to go. You still have to feed that back through the response.getWriter() and make sure your contentType is text/xml. I'm testing it out some more today.

What I am using it for is trying to see if it saves me from having to save all the form data in the session just to change 1 thing on the page. There seems to be about equal work both ways but that may be because of my newbie-ness with XMLHttpRequest and Javascript.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

XML would be the way to go



I'm not so convinced. XML is a great mechanism for data transport -- but it's a bear (in a bad way) to parse in Javascript. I've also seen a technique in which Javascript object literals were returned. Obviously this limits the utility of the data to that one usage, but it's a lot easier to deal with in the JS code.

There seems to be about equal work both ways



Aside from the amount of development work, another consideration is the "user experience". The whole reason I used the "sub-request" mechanism in BlackBox was because all the flashing and redrawing after each play was annoying and disconcerting. Even if it's the same amount, or even slightly more, work than the traditional mechanisms, it might be worth it if it makes your users happier campers.

Again, once I start playing with it (timeframe unknown, I'm up to my eyeballs in stuff right now) I'm fully expecting other shoes to drop and for there to be unforseen issues that need to be resolved.
[ April 15, 2005: Message edited by: Bear Bibeault ]
 
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Right now I am writing a book on this, not positive if you know that.

I am working on examples on using responseXML and responseText.

There are times that I think you should just use text and not use XML. Reason for this is you need to process the data on the server, why bother processing it again on the client?

I am still trying to think of an example in my book using the eval method. Only things I could think about was with games, but that is not the scope of this book.

I think the double combo is one of the best examples in why you would want to use AJAX. Plus you do not have to return much of anything. I think one of the useful factors of this is being able to update session variables.

You are able to make a communication link between the server and the client which you had to use unreliable or obtrusive methods. The XMLHttpRequest method gives error messages that you can handle, can not say the same about iframes, popups, hidden frames, and applets.

If you think I should try covering something in my book, give a yell, I am finishing up the TOC today!

Eric
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic