It's 7:50 pm on Sunday, and I'm still working. I figured I'd share why I'm debugging like crazy instead of relaxing.

Bindings.

For those of who know of Flex 2, Adobe's tool for programmers to create Rich Internet Applications, it has this one feature that sets it apart from Flash, and incidentally, its brother Spry shares. It allows you to put a variable surrounded by curly brackets, and at runtime, anytime that variable changes, it'll update whatever variable is being set to it. So, for a TextField, you can bind a global text property to the TextField's text property, like so:

<mx:Label text="{message}" />

And when you update the message variable, the Label's text property will automatically be updated. Utilizing Cairngorm, a lightweight MVC application architecture for Flex, you can take this concept a step further using ModelLocator. This is basically a global (static) class that holds global data. You can have your Views' (your visible forms) bind to these variables. Anyone who updates the ModelLocator (in this case the Model) has suddenly updated the entire app. Nice!

...that is, until something goes wrong. These bitches are hard as nuts to debug. It's even worse when you are binding to a nested property, or a set of forms and their children all bind to the same thing. Through copious refactoring, the parent view is the only one who actually binds to the ModelLocactor. The rest using public getter / setters, and use their internal private variable (Flex 1.5 only has public / private, not protected like Flex 2) for the binding. This makes it easier to debug, but not awesome. You know you're in deep shit when you're forms start getting updates, 1 frame later mind you, and have a COPY, not a reference of a ValueObject. Yes, that's right, I said a COPY, not a reference. Array's and Objects in general are always passed around in Flash by ref, so naturally I'm freaking out.

Anyway, what I have learned from this? Two things. Common literary rule is to ensure all lists have at least 3 entries, but I'm using 2 I feel they are important.

1. Make the top level View use ModelLocator for binding; all children can propagate internal copies. If you have a View that uses ModelLocator, and his parent uses ModelLocator also, your code sucks, fix it. Refactor it into a binding tag, binding to a getter / setter, or a public property. You'll thank me when you go to debug and you KNOW who's setting who, and when.
2. Handle null. If you're View can't handle null, it sucks. The old saying is a good acid test for your View; Garbage In, Garbage Out. If you throw a ValueObject at a form for example to edit it, and bind to the changes, fine. If it takes a null, and disables itself, fantastic. If you're View can't take a null, you know what you have to refactor.

On a lighter note, in the free milliseconds I've had in the past month to play with states & transitions in Flex has taught me another 2 things:

• States and Transitions are the bomb. It makes your View's much more flexible, allows you better control over user eye tracking (look here sucka), and good integration with event handling.
  
• Flex without Flash blows - Flash & Flex together can make some phat interfaces. AS3 & Component powah, Flash funk; good stuff.
  

I'll be showing some of the cool stuff you can do with the above August 3rd here in the ATL, August 14th in New York City, and October 23rd (ish) at MAX in Vegas. Hope to see you at one of 'em and make you go, "Awww... hell yeah!".

...and back to the mutha-fD)($Ring grind.