Greg Murray's Blog

AJAX - X = No Dice

Most of the focus I seen in the AJAX world seems to revolve around the JavaScript and DHTML operations on the client. Without the 'X" in AJAX you really can't have any rich interaction. At JavaOne there has been much talk about AJAX. There have been some discussions about server-side AJAX components returning other content types than XML. Below are two general models I see with AJAX today. While there are other strategies the two below summaries much of what is used today.

• Returning XML/XML Fragments - This strategy allows for structured data to be interchanged. This strategy requires the server-side component that processes the AJAX request to set content-type header of the HTTP response is set to "text/xml". The benefit of this approach is that you may retrieve a DOM object representing the XML document returned from the server-side component in the callback of a the XMLHttpRequest by calling XMLHttpRequest.responseXML. You may navigate programatically the DOM and extract data from it or insert into the HTML DOM. Consider this strategy if you want to deal with structured data. Also consider this strategy if your server-side AJAX processing code needs to communicate with additional clients other than AJAX clients such as standalone clients, Java applets, or Flash clients that may want to use the same server-side processing.
• Returning Plain Text - In this case simple text is returned. The text may be retrieved by client-side JavaScript callback method by calling XMLHttpRequest.responseText. The text may be further processed on the client-side JavaScript or inserted into the document using the JavaScript DOM APIs or by setting the innerHTML attribute on an element to the text. Calling XMLHttpRequest.responseXML on a plain text will result in an error. JavaScript may also be passed as text and futher evaluated on the client. Generating client-side JavaScript using a server-side component could potentially bind the server-side AJAX code to a specific usecase. One interesting use of this strategy is the Dynamic Web Remoting (DWR) framework which uses AJAX to do RPC calls on server-side Java objects.

What type of content do you pass around with AJAX?

Comments

• Considering in web applicaiton while using JavaScript.
  JSON[www.json.org] may be a good idea:)
  see swato [http://swato.dev.java.net]

  Posted by: zigzag on July 05, 2005 at 09:38 PM

• Trackback:
  Greg Murray recently noted that AJAX does not need to use XML (although he clearly likes the idea). He refers to DWR using text/plain in it's place. I thought it was worth noting how DWR handles XML...
  [More]
  

  Posted by: joe_walker on July 06, 2005 at 02:17 AM

• I've used XML and plain text depending on what the situation lended itself towards. I find that in situations where the response values is simply going to be inserted directly into the document as is, plain text makes a lot of sense because it limits the overhead of XML processing and the overall use is just easier. If on the other hand I want to use the same data in multiple pages or I want to specially processes that data, maybe by applying some extra HTML tags to it, then XML makes more sense. Another way of handling the data is by using the response header. Since the XMLHttpRequest object can also access the response headers directly it may sometimes be advantageous to place data there.

  Posted by: grabity on July 06, 2005 at 05:57 AM

• I added this sort of approach to an application in 2001 when I noticed that Mozilla had added a compatible variant of MSIE's XmlHttpRequest. The specific use case was a form where users entered unique names of a complex indexed entity, and when committing the HTML entry form, the server would have checked validity then had to redraw the form with all data and also possible suggestions for alternatives when indexed names were already in use.

  In that case, the little abstraction layer I developed (a simple reusable JavaScript and a few server-side classes to read/respond to committed data) let me provide fast feedback for the user, without glitchy refreshes, and helpfully suggested corrections.

  For me, the key is only to use it when there's a need (improve complex form behaviour that's just as annoying as constant post/refresh cycles to develop) or real infrastructure benefits, such as avoiding sending huge HTML pages when you can pull XML and XSL in JavaScript and transform (and even retransform multiple datasets with in-memory cached XSLT documents).

  There are other use cases too. Having said that, if I could have used javawebstart, I would have, as it's better suited. Depends upon deployment constraints too.

  Posted by: chris_e_brown on July 06, 2005 at 08:36 AM

• In addition to JSON, consider JSON-RPC. It too uses XmlHttmRequest but uses JSON syntax to communicate RPC information. I did a small prototype at home and it was quite nice.

  http://oss.metaparadigm.com/jsonrpc/

  Posted by: trinition on July 06, 2005 at 09:43 AM

• The title "No Dice" is too extreme. We're only beginning to uncover the utility of dynamically fetching JavaScript.

  XmlHttpRequest will be supplanted by DOM Level 3 Load&Save, which unfortunately supports fetching only XML.

  Why the asymmetry that HTTP requests needn't use XML but HTTP responses supposedly should. If XML is so important to integration, why aren't browsers using SOAP. Maybe XML isn't as fundamental as you suggest.

  Posted by: bmiller on July 07, 2005 at 08:42 AM

• 
  When I considered the title for the post I thought "AJAX - X = No Dice?" might be a little more true. When reading about AJAX I see most of the focus on the client-side script.
  With the catchy title of this blog I wanted to point out there is more to AJAX life than the client-side of the interaction. A web application can provide the best UI and interactions in the world but it would be nothing without the content. Whether the client and server communication is XML or plain text which might be further evaluated I believe it is dependent on what you are trying to do. It is good that the XMLHttpRequest object can support a wide set of use cases.

  
  So do I think XML is important for AJAX? Yes. There is a great deal of structured data out there and there are many cases where it makes sense to use it as a means of exchange. Is XML the only solution for every problem? No. From the responses so far it is good to see that there are a nice set of frameworks being developed to make the "odds" of client-side AJAX scripting less "risky."

  
  

  Posted by: gmurray71 on July 07, 2005 at 04:37 PM

This work is licensed under a Creative Commons License.