Chapter 9. XML Requests and Responses: More Than Words Can Say

How will you describe yourself in 10 years? How about 20?

Sometimes you need data that can change with your needs... or the needs of your customers. Data you’re using now might need to change in a few hours, or a few days, or a few months. With XML, the extensible markup language, your data can describe itself. That means your scripts won’t be filled with ifs, elses, and switches. Instead, you can use the descriptions that XML provides about itself to figure out how to use the data the XML contains. The result: more flexibility and easier data handling.

Note

As a special bonus, we’re bringing back the DOM in this chapter... keep an eye out!

Classic rock gets a 21st century makeover

Rob’s Rock and Roll Memorabilia has hit the big time. Since going online with the site you built for Rob, he’s selling collectible gear to rich customers around the world.

In fact, Rob’s gotten lots of good feedback on the site, and he’s making some improvements. He wants to include a price for each item, in addition to the description, and he also wants to be able to include a list of related URLs so customers can find out more about each item.

How should a server send a MULTI-valued response?

So far, all the server-side programs we’ve worked with have sent back a single piece of data, like -1 or “okay.” But now Mike wants to send back several pieces of data at one time:

A string description of the selected item.
A numeric price for the item, like 299.95.
A list of URLs with related information about the item.

What would you do?

There are lots of ways to handle getting more than one value back from the server, and this time, the choice is up to you. What do you think?

Jill: I don’t know, Joe. That’s a lot of formatting for the server-side guys to keep up with.

Joe: But they’ve got all the data about the item, right?

Jill: Well, sure... but server-side programmers don’t really like to mess around with XHTML. That’s the whole reason a lot of these folks move over to the server-side in the first place... no XHTML.

Joe: But the CSS doesn’t change that much, so the XHTML won’t change that often.

Jill: Oh, the XHTML will change sometimes?

Joe: Well, sure, maybe... but not very often. Only if we need to add a tag, or maybe an ID for CSS...

Jill: Oh, no. You’re not going to be able to get server-side guys to write XHTML, and then change it all the time on top of that.

Joe: Hmmm. This is sounding harder than I thought. I thought innerHTML was going to be really simple...

InnerHTML is only simple for the CLIENT side of a web app

From a client-side point of view, innerHTML is pretty simple to use. You just get an XHTML response from the server, and drop it into a web page with an element’s innerHTML property.

function displayDetails() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      detailDiv = document.getElementById("description");
      detailDiv.innerHTML = request.responseText;
    }
  }
}

The problem is that the server has to do a lot of extra work. Not only does the server have to get the right information for your app’s request, it has to format that response in a way that’s specific to your application. In fact, that format is specific to one individual page on your site!

If you were a server-side developer... which would YOU prefer?

Frank: I’m not sure, Jim. Something’s bugging me about this CSV thing.

Jim: What, just because I’m already almost done?

Frank: No, seriously. It just seems so ... I don’t know. Inflexible?

Jim: What do you mean? Here, look at my code to take the server’s response in my callback, and update the item detail for the page. It’s a little long, but it’s all pretty basic stuff:

Brain Barbell

Why do you think the loop deleting any preexisting elements from the details <div> counts down, instead of counting up?

If you’re stumped, try reversing the loop and see what happens. Can you figure out what’s going on?

Brain Power

What do you think Frank meant on the last page about CSV being inflexible? Are there problems with the server’s response being in CSV that adding new types of items might cause?

Jill: Sure, XML is easy. The server-side guys shouldn’t have any problem with that at all. It’s certainly a lot better than XHTML...

Frank: Yeah, I heard Joe was working on that. The server guys couldn’t get him an XHTML response?

Jill: Well, they could’ve, but nobody wanted to. XHTML is a mess to work with on the server, and it changes all the time.

Frank: You know XHTML is just a flavor of XML, right?

Jill: Sure, but lots of people and apps can use XML. Dealing with a certain <div> with this id, or only using <p>'s and not <br />'s... that’s pretty fragile.

Frank: No kidding. Well, I’ve got to rewrite my callback, but let me know when the XML response is ready, okay?

XML is pervasive in the programming world. If you respond in XML, LOTS of different applications can work with that XML response.

You use the DOM to work with XML, just like you did with XHTML

Since XHTML is really a particular implementation of XML, it makes sense that you can use the DOM to work with XML, too. In fact, the DOM is really designed to work with XML from the ground up.

Even better, the request object you’ve been using to talk to the server has a property that returns a DOM tree version of the server’s response. That property is called responseXML, and you use it like this:

Rob wants data that changes depending on the request.

If you ask the server for details about a guitar, you’ll get a manufacturer and year. Clothing? A manufacturer, sure, but also a size. And for bands, you’ll get a band name, and possibly the name of the individual in the band that the item belonged to or is associated with.

How would you handle a changing response from the server? And who’s better equipped to handle this new requirement? Frank, with his XML, or Jim, with his CSV?

You may not have known...

≠	...that just as the browser sees your HTML as a DOM tree, web browsers automatically convert any XML they have to deal with into DOM trees.
≠	...that you can work with more than one DOM tree in the same JavaScript function. For example, you can read an XML DOM tree and update an HTML DOM tree, all at the same time.
≠	...that HTML elements and XML elements are both just element nodes in the DOM. There’s no difference between an XML type and an HTML type, at least when it comes to the DOM.
≠	...that the responseXML property always returns a DOM document object, even if that object is a single element, or just a single text node.

Frank: Yeah, I’ve got a lot of changes to make, too. But I was thinking... Jim, how are you going to handle a changing response with your CSV?

Jim: Well, I was thinking about that...

Joe: Hey, guys, I had an idea. You know I’ve been doing some research—

Jim: So I think what I can do is assume that every other value is a category, like “Description” or “Price.” And the values after each category are the actual category values, like the textual description, or 399.99, or whatever.

Frank: Hmmm. Sounds a little hairy.

Jim: It’s not too bad. Except for cases where there’s more than one value, like for those URLs? Then I think I have to check for maybe a special character before each category to indicate that it’s a multi-value category.

Joe: Listen, guys, I wanted to show you—

Frank: Wow, Jim, that’s nasty. Sounds like this latest change from Rob is really going to be a pain.

Jim: Yeah, it kinda is. But what else can I do?

You can’t always know in advance what the data structure you get from the server will look like.
And even if you do, that format might change... at anytime.

XML is self-describing

The thing that’s cool about XML is that you can create your own vocabulary. XHTML is an XML vocabulary that’s specific to displaying things on the web. But suppose we needed a vocabulary for describing items, like at Rob’s online store.

But the format can’t be locked into elements like <price> or <resources> because we want each item to define its own categories. We might use something like this:

Exercise

It’s time for the big finish (at least for now). Your job is to take what you’ve learned about the DOM, server-side responses in XML, and the format from the last few pages, and put it all together. Here’s what you’ve got to do:

	Change your request URL to use getDetailsXML-updated.php. That script is in with the other downloads for this chapter from Head First Labs.
	Rewrite the displayDetails() callback to work with the XML vocabulary we’ve been looking at. Remember, you may get more—or less—categories for different items. And you’ve got to handle those list categories, too.
	Test everything out! Once you’ve got everything working, turn the page to claim your Les Paul (at least, that’s what we hope)!

What’s Joe talking about?
What ever happened to innerHTML?
And how does he plan to top XML?
Find the answers to these questions and more... all in Chapter 10.

Q:	Q: What is CSV again?
A:	A: CSV stands for comma-separated values. It just means that several values are put together into a single string, with commas separating each individual value.
Q:	Q: I’ve also heard about TSV. Is that similar?
A:	A: TSV refers to tab-separated values. The idea is the same, but tabs are used instead of commas. In fact, you can use anything you want to separate the values: a pipe symbol (`\|`), an asterisk (`*`), or anything else that’s a fairly uncommon character.
Q:	Q: Why do you need to use an uncommon character to separate values?
A:	A: If you use something common, like a period or letter, that same character might show up in your data. Then, your JavaScript might split the data incorrectly, giving you problems when you display or interpret that data. In fact, CSV is a bit dangerous because an item description might have a comma in it. In that case, you’d end up splitting the description on the comma, and having all sorts of problems.
Q:	Q: So is that why we shouldn’t use CSV?
A:	A: Good question. Frank, Jim, and Joe are still debating the merits of CSV, but you could always swap out those commas for something else, and change your client code to split on that new character instead of commas. As for whether or not you should use CSV, you may want to keep reading...
Q:	Q: What is setAttribute()? I’ve never seen that before.
A:	A: `setAttribute()` creates a new attribute on an element. The method takes two arguments: the name of the attribute and its value. If there’s no attribute with the supplied name, a new attribute is created. If there’s already an attribute with the supplied name, that attribute’s value is replaced with the one you supplied to `setAttribute()`.
Q:	Q: What about childNodes? What’s that?
A:	A: `childNodes` is a property on every DOM node. The property returns an array of all the child nodes for that node. So you can get an element’s children, for example, and iterate over them or delete them.
Q:	Q: So why did you iterate backwards over the childNodes array?
A:	A: That’s a tricky one. Here’s a hint to get you thinking in the right direction: when you call `removeChild()`, the node you supply to that method is removed from its parent immediately. That also means that all references to that now-removed node—say in an array full of an element’s child nodes—have to be updated. Without a child to point to, all the child nodes that come after the removed node have to be moved up in the array. So if you iterated over an array like `childNodes` from front to back, removing nodes as you went, what would happen?

Q:	Q: So the big deal about XML is that it describes itself? That can’t be useful all that often...
A:	A: Actually, self-describing data is useful in a number of situations, just like here, with Rob’s online store. It’s pretty convenient to be able to define elements and structure that’s suited to your business. Even better, XML is a standard, so tons of people know how to work with it. That means your vocabulary is usable by lots of programmers, in client-side and server-side programs.
Q:	Q: Wouldn’t it be easier to just make up our own data format?
A:	A: It might seem that way at first, but proprietary data formats—ones that you make up for your own use—can really cause a lot of problems. If you don’t document them, people may forget how they work. And if anything changes, you need to make sure everything is up-to-date: the client, the server, the database, the documentation...that can be a real headache.
Q:	Q: Okay, I get why we should use XML, but doesn’t it become a “proprietary data format” when we start declaring element names?
A:	A: No, not at all. That’s the beauty of XML: it’s flexible. The server and the client need to be looking for the same element names, but you can often work that out at run-time. That’s what’s meant by self-describing: XML describes itself with its element names and structure.

	XML is the best choice. Frank’s gonna win.
	CSV is simple and functional. Go, Jim!
	innerHTML: it ain’t broke. Joe’s got it in the bag.