Skip to the last sentence for the advice.
Many Flashers already know about the caveats one faces when going from Flash Player 6 to Flash Player 7 development in dealing with case sensitivity. This new feature helps speed, and also allows for more freedom of naming in code since color can now be an instance of the Color class. Additionally, one mispell of mY_btn (instead of my_btn), will have the Output gettin’ all in yer face about “Yo, this variable doesn’t exist anywhere man… weird, what’s he doing here?”. It’s nice to know an uppercase Y makes one so distinctive. How about a capital J, biotch!?
Anyway, re-writing some AS1 XML parsing code, and it was working fine when I published to Flash Player 6, but not 7. I was like, wtf. So, started debugging, making mad traces, long debugging window sessions, digging deep in XML objects in the Debug Window to inspect each and every property.
Turns out, someXmlNode.attributes.href is different than someXmlNode.attributes.HREF. You may go, “No sh… thanks for wasting 3 paragraphs of my life Jester.” If your still here, you r0x0r. Ah… but is href a variable or a string? Attributes in XML have the neat distinction of being neatly placed on a vanilla object called “attributes”, so you can access them like you would any other plain object, such as a data provider item (item.label). Because they are vanilla, though, you typically don’t have classes defined that represent them. For instance, EventDispatcher, when it does a dispatchEvent, throws out an object. You’ve seen the familiar syntax:
dispatchEvent({type: “event”, target: this});
It’s just “known” that you make at the very least a type attribute, and usually a target. The “known” attitude is what led us from Flash MX to Flash MX 2004. No more mispellings of variables, objects… we now have real-world syntax checking!
But again, you can’t for vanilla, one time use objects like EventDispatcher and the XML Object’s attribute construct do. Therefore, one must be extremely careful. For the knowns, like label and data, or for events like type and target, your fine because everyone and their mom knows you type it in lowercase.
However, for some events, they aren’t. For instance, all UIComponents get “focusIn” and “focusOut” events. See the capitalized In and Out? Tricky, tricky…
XML is even worse. The second you utilize an attribute, you’ve immediately hardcoded your code. Now, as a seasoned Flash developer, I’m cool with that. XML parsing is my daily bread, and it’s just known that you quickly navigate your document to get the data in. Some people think that using recursion is more encapsulated, but that is dangerous as hell in Flash, can be slow for large objects, and if your in your Model class, who gives a flying flizz-narg?
So, just some advice. When parsing XML attributes, make sure your capitalization in your XML node’s attributes (or internal structure) is the same as what your using in your code.