Posted on by JesterXL

Binding in the Trenches

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, it’s 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.

8 Replies to “Binding in the Trenches”

  1. Good Advice Jesse. :)
    Yeah folks don’t realize if you are using code and value assignment to handle the same thing in multiple places – you have problems. Its way easy to get sucked into it though.

    So Atanta, NYC and Vegas but no Austin? Dang.

  2. Who says you have to have >2 items to make a list? Those who say that are either:
    1. Overlooking the fact there are good cases for having 2 items.
    2. More worried about rules than context… as the ‘i before e except after c’ fools.

  3. Thanks for posting on this topic, Jesse. There seems to be about a dozen different ways to bind. All of them with their quirks. I’ve been trying to find a consistent way to use binding that will keep me out of trouble. This post offers some good guidlines.
    I’ve put down my own binding methods in step 6 of my post here. Seems to be working well so far. :D
    Cheers.

  4. Also, if you see problems with binding, try BindingManager.debugBinding.
    Cheers,
    Ralf.

  6. i don’t really see a need for binding when you can just use a static variable or a static class?

  7. Ok…noone, let’s take your case for instance.

    //AS 2.0
    class data{
    public static var Name:String = ‘noone’;
    }

    Now, to use that var you would do the following, right?

    import data;
    class section{
    function section(){
    _root.name.text = data.Name;
    }
    }

    So, you have that done and you’re good to go right. What happens to name.text after youupdate data.Name?

    import data;
    class section{
    function section(){
    _root.name.text = data.Name; //value is ‘noone’
    data.Name = ‘John’;
    trace(_root.name.text); //value is ‘noone’
    }
    }

    Now, if name.text was bound to data.Name the text property of name would stay updated with the value in data.Name.

    Having used static classes too much I know where you are coming from but trust me/us…take the red pill. ;-)

    Disclaimer:
    Sorry for the AS 2. It comes more natural than AS 3 at this point. If Jesse integrated code completion (IntelliSense or something), it would be easier to comment with code. :-) j/k Jesse.

Comments are closed.