Do you really need XML for an Ajax application? The previous chapter showed that you don't always need XML. In particular, if you only have one data point, XML is overkill. But the fact is, most web applications deal with multiple data points: usernames, passwords, addresses, cities, states, zip codes, etc. How will you decipher those fields when they're sent back from the server?
In some cases, passing a string of delimited values may seem like the simplest approach, but using XML has advantages. For one thing, XML is self-documenting. During debugging, you can look at the XML string and see exactly what goes where; that is a luxury you won't have with a string of comma-separated values.
The Character Decoder
The example in this chapter is similar to the one in the previous chapter, but instead of the server returning one data point, it's going to return five. Retuning a small collection of data shows what happens when you go beyond a single data point and illustrates why most Ajax applications need XML or some other way to structure the data that is passed from the server to the client.
Figure 4-1 shows how the user interface of the application will look when we're done. The design is simple enough: we send a character to the server usingXMLHttpRequest(), and the server responds with aString containing the five conversions in XML format (decimal, octal, hexadecimal, binary, and HTML). Thecallback()function in the client then calls a function to parse the XML and populate the fields in the browser.
Figure 4-1.The complete Ajax Character Decoder example
Now it starts to get fun. One keystroke fills in all the data fields, and although it doesn't look like much is going on from the user's perspective, from the programmer's perspective we know that the application is communicating with the server without a clunky submit or reload or any waiting for the page to refresh.