Event-Driven Functionality

Now that our XML reader works, let's break it. We will fundamentally reengineer the highscore object. Modern programs avoid polling when possible. But our function now is spread over four frames , as it loops around and tests the xml.loaded flag. We can do better.

onLoad Callback Function

Flash encourages us to create our own function and install it as the onLoad method. The code we install there is called (by Flash, not by us) when the whole XML file is loaded or when a load failure is recognized.

Formalism

The syntax is relatively simple: You declare a function and then set your xml.onLoad equal to it:

ActionScript

 function gobblexml( loadedOK ){     if ( loadedOK )         { do stuff} } xmlobject= new XML(); xmlobject.onLoad= gobblexml(); 

Or you can be more concise by combining the definition of the function with its assignment to onLoad . In that case there is no necessity to give the function a silly name .

ActionScript

 xmlobject.onLoad= function ( loadedOK ){     if ( loadedOK )         { do stuff} } 

Execution Context

The onLoad handler is bound, clearly, to a very specific XML object. In turn , this object exists within a MovieClip instance, on a particular timeline, with its own variable scope. One would expect that when onLoad executes, it will be able to address as siblings other objects on the same timeline, that it would address the parent clip as _parent , and that it could direct its own timeline execution with play() and stop() . But one would be wrong. One would, in fact, pull out one's hair in big clumps, one would shake one's fist in the air, but one would not be able to address any variable or MovieClip in the application. Eventually one would realize that the context of onLoad 's execution seems to be at the root. All relatively addressed objects are reached as if called from the root. One would not be particularly pleased. Addressing objects from the root ( essentially using absolute addressing) is a terrible coding practice. It makes for brittle, dangerous code. One wants flexible objects ”like this highscore feature that can just be snapped into any game and behave as a little independent XML receiver. It certainly does not know or care where it lives in the object hierarchy.

In fact, onLoad executes within the private context of the XML object to which it is linked. (Though this context seems aligned to the root, even that is not guaranteed .) The object's properties include nothing that indicates its own address space. (By contrast, a MovieClip has _parent and _target .) So how does the onLoad code address the clip it lives in?

The answer is delightfully simple. The programmer can create the missing property. After constructing the XML object and before releasing it into the asynchronous load, the initialization code creates a variable in the XML that points back home:

ActionScript

 YourXML.clip= this; 

works fine. Inside onLoad , we can address a sibling variable as this.clip.foo.

Upgrading highscore

All the logic for this object is now in frame 3. We can haul it all out and repackage it inside the onLoad function. It cleans up pretty well in the process.

There are getting to be too many things named highscore, so the high score XML object is renamed hsml. The highscore MovieClip is pointed to by hsml.display:

ActionScript

 hsml= new XML(); hsml.display= this; hsml.onLoad= function (success ) {   if ( !success )          this.display.winner = "HIGH SCORE data is unavailable";   else{      if( this.firstChild.nodeName.toLowerCase() ne "highscore" )          this.display.winner = "HIGH SCORE data is corrupted";      else{          this.display.score =  this.firstChild.attributes[ "score" ];          if (this.firstChild.firstChild.nodeValue.length)             this.display.winner = this.firstChild.firstChild.nodeValue;          }      }    this.display.nextFrame();  }   hsml.load("highscore_winner.xml");   stop(); 

An anonymous function is made the onLoad handler for the hsml object. The load is initiated, and the MovieClip is stopped on this first frame. There are absolutely no graphics. We just wait for onLoad to be called.

When it is called, onLoad is passed a success code. If the code shows failure or the XML isn't recognized, the handler selects the appropriate error message. (We will be using the display line meant for the winner 's name.)

If the code passes those two tests, it records the score (using the pointer we made to the MovieClip instance). If there is a winner's name, it records this as well. It then proceeds to the next frame.

The second frame is all graphics and no code (Figure 8.3). The movie just stops there and displays the information it extracted from the XML file. All this proceeds asynchronously; we just set it up and forget it. We just throw this object anywhere and it'll just plain work. In fact, it will work in any game as long as the website that serves the game keeps a highscore_winner.xml file in the same directory.

Figure 8.3. The Second Frame