Loading and Sending XML | Inside Flash MX (2nd Edition) (Inside (New Riders))

All the XML functionality for Flash 5 is encapsulated into two objects, XML and XMLSocket. The XML object is used to load and send XML via HTTP. It's also used to manipulate XML. This is the object that you will use most often. The XMLSocket object is used to send and receive XML over a direct socket connection with a special piece of server software. This is used for real-time two-way communication, but because there are only a few commercial server options for XMLSocket, its use isn't yet commonplace.

Creating XML Objects

So how do you create a new XML object? It's relatively simple. All you have to do is type this:

 myXML = new XML();

This statement creates a new variable, myXML, and sets it equal to a blank XML object. You can also specify a string of XML inside the parentheses that should be parsed. For example, you could enter this:

 myXML = new XML("<foo>bar</foo>");

Although you can do this, it's not a commonly used method for loading XML data especially for any XML data that exceeds a line or two. The much more common way of getting XML into an XML object is to use Flash's built-in load method for the XML object:

 myXML.load("info.xml");

This loads a pre-existing XML document into your myXML object.

Now that you know you can load external XML documents, you might be thinking that you can use XML that exists on a server other than your own. But hold on a minute. It is possible to load XML from other servers, but those servers have to be within the same second-level domain that your Flash Player file exists on. For example, if you have an SWF on the server www.foo.com, you could load XML from xml.foo.com or blah.foo.com, but not from www.bar.com. This security restriction occurs only when viewing SWFs with the Flash plug-in. If you're using the Standalone Player, you can load XML from anywhere you want (provided that you have an Internet connection, of course!).

Tip

If you absolutely must load XML from an external domain from within the plug-in, you can, but it requires the use of some server-side technology, such as Macromedia's ColdFusion or Microsoft's Active Server Pages. Basically, you need to create a page under your local domain that can be passed an external URL and then output the actual contents of that external URL. In other words, you need a simple redirect. Consult your local server-side guru if you need help actually constructing one because they are different in every language.

Loading XML Data

If you use XML much, you'll quickly discover that there are two main types of XML parsers out there, Simple API for XML (SAX) and Document Object Model (DOM) parsers. SAX parsers are event-based . This means that as the parser receives XML tags, it lets you know what it received. DOM parsers wait until they have received a full XML document and then turn that document into an object-based data structure. As it happens, Flash's XML parser is DOM-based, so it can't do anything with your XML until the entire XML document has finished loading. To deal with this, Flash's XML loading mechanisms are asynchronous. In other words, your movie will keep playing while Flash tries to fully load your XML document. After Flash loads the XML, it then parses it into a data structure. When the parsing is complete, the XML object automatically calls its own onLoad method.

Think about that for a minute. You have to wait for the XML to load and get parsed before you can do anything with it. That's latency, and latency is a fact of life when you're uploading data. Get used to it, and be prepared to deal with it. You can't use the data that you're uploading until it's available.

Flash's internal onLoad method for the XML object doesn't actually do anything. That has a tendency to confuse people. The whole point is that you are supposed to override the onLoad event to make it do what you need it to do.

By overriding this method, you can make Flash let you know as soon as it's done loading and parsing an XML document. When Flash calls the onLoad method, it automatically sends as an argument: a Boolean value stating whether the XML received was valid. The code to override the onLoad method would look like this:

 // Create your object  myXML = new XML();  //Create your onLoad function  myXML.onLoad = function(valid){     If (valid){         trace("got good XML");      }else{         trace("got bad XML");      }  }  //Load your XML  myXML.load("somexml.xml");

As soon as your somexml.xml document is fully loaded, you'll see either "got good XML" or "got bad XML" in the output window. That's not particularly useful, but at least you're getting some information.

Exercise 23.1 Overriding the XML Object onLoad Function

In this exercise, you'll set up a basic onLoad override. In later sections, you'll build on this, so make sure that you understand this part.

Create a new Flash file and save the file to your hard drive.
Copy the XML file that you're going to be loading (plantList.xml) to the same directory as your FLA file.
You need to create your new XML object now. Rename Layer 1 as Actions. Select frame 1, launch the Actions panel, and enter the following code:
```
 // create your new XML object  plantXML = new XML(); 
```
You can do one of two things now: You can load the XML, or you can write the function to override the internal onLoad event. It doesn't really matter which order you do these in. For this exercise, you start by creating the function that will get called when the XML loads.

Beneath the lines of code you just entered, add this:

 // create your onLoad function  plantXML.onLoad = function(valid) { }

What do you want to test for? If the value of valid evaluates to true, you know that you've got good XML. Otherwise, you have a problem. Set up the appropriate if/else statement with traces so that you can see the outcome in the Output window. Between the curly braces, add the following code:
```
 if (valid) {         trace("Got good XML.");      }else{         trace("That's just not right.");      } 
```

Now it's time to load your XML. After the last curly brace , enter this:

 // Load your XML  plantXML.load("plantList.xml");

At this point, your code should look like this:

 // create your new XML object  plantXML = new XML();  // create your onLoad function  plantXML.onLoad = function(valid) {     if (valid) {         trace("Got good XML.");      }else{         trace("That's just not right.");      }  }  // Load your XML  plantXML.load("plantListStructured.xml");

Save your work and test it.

If you've entered your code correctly and both the Flash file and the XML file are in the same directory, the Output window should pop up with the message "Got good XML."

So now you know that you're actually receiving XML data through the XML object. What about sending it?

Sending XML Data

To send XML to another application, you use either the send or the sendAndLoad methods of the XML object. The only difference between the two is pretty obvious: sendAndLoad sends XML to a URL and expects a response back, while send is a " fire-and-forget " solution. Here's a quick example of send:

 MyXML.send("/scripts/somescript.asp");

The sticky bit with sending XML to the server comes with the server-side program to which you are sending the XML. This is an issue because the actual send is done via POST, and the MIME type of that POST data is application/x-www-form-urlencoded , which manages to confuse the heck out of many servers. This is because, unlike most POSTs, the ones coming from Flash are not name /value pairs; instead, they are just raw XML. When you are developing the server-side program that will "catch" the XML, keep this in mind because it is the most common source of trouble by far.

At this point you might be scratching your head. MIME types, POST, urlencodedwhat is all this stuff? MIME stands for Multipurpose Internet Mail Extensions. The MIME type is also known as the content type or media type. These are codes that tell the server what to do with specific file types and what information about those file types to send back to the browser. The browser then uses that information to fire up the appropriate helper application. Each MIME type has two parts : a type and a subtype. The type indicates a general category, such as application, audio, image, text, or video. The subtype further refines the type of application, image, and so on being sent. The type and subtype are always separated by a slash (/).

Additionally, there is the issue of sending information from Flash via POST, which is what the XML object does. There are two ways to send data back from Web browsers to servers: GET and POST. GET sends the information via variables on the URL string. POST sends the variables in a separate HTTP header.

What does this have to do with XML? The original release of the Flash 5 Player always sent a MIME type of application/x-www-form-urlencoded this is what you commonly use with CGI and ASP scripts; it sends the data as name/value pairs separated by ampersands (&). However, with the XML object in Flash 5, the information returned by the POST isn't in name/value pairs; it's raw XML data. This caused problems with some XML servers. The newer release of the Flash 5 Player has a new XML property called contentType that enables you to set the MIME type to whatever you need it to be (for example, application/xml).

If you know for sure that your clients will be using the R41/42 (or later) version of the Flash player, you can use the new contentType property of the XML object. If you're putting your content on a public site, you probably don't want to assume that everyone has R41/42. This property just holds a string that will be used as the MIME type of any XML sent from that object. The format for the contentType property of the XML object looks like this:

 MyXML.contentType = "application/xml";

If you're loading XML, you'd probably like to know how to use it.