Dynamic Flash

Databinding has to be just about one of the coolest features in Flex 2, allowing you to bind a property to the value of a property of another object. When the property of that object is updated, the value of the bound property will automatically be updated. This is mainly used in Flex to update UI components when the data for the model changes.

Unfortunately databinding doesn’t work for read-only properties. A read-only property (by my definition) is a private instance variable of a class that has a getter function without a matching setter function. Something like this:

package {
  public class User() {
 
    public function User(name:String):void {
      this._name = name;
    }
 
    private var _name:String;
 
    [Bindable]
    public function get name() {
      return this._name;
    }
 
    public function addTitle(title:String):void {
      this._name = title + " " + this._name;
    }
  }
}

Here the name property of the User class is read-only from outside of the class. This is useful if you won’t want other developers (or other classes) from messing with the values of an object, and in doing so helps you to property encapsulate your data and logic. I’ve also concocted an addTitle method that changes the value of the name property, just so we have something to call to demonstrate databinding.

To make the name property bindable I’ve added the [Bindable] metadata tag just before the getter function. The [Bindable] metadata tag is used to enable properties to be used as the source of databinding operations, and the Flex compiler picks up on this metadata tag and adds in some extra code to your class to implement data binding at compile time.

This looks as though it might work, but sadly it doesn’t. You’ll get the following warning from the compiler:

[Bindable] on read-only getter is unnecessary and will be ignored.

While I disagree whole-heartedly with that statement – if it was unnecessary we wouldn’t be trying to bind to it – I can see where they’re coming from. (Note to Adobe: This is what happens when you let programmers write error messages). The reason it doesn’t work is that databinding requires a matching setter function – and for that setter function to be used internally whenever changing the property value – in order to detect changes. As mentioned earlier, the Flex compiler adds code to your class that fires an event whenever the setter function is invoked. Without this event there’s no way for anything bound to that property to know it has changed.

The solution to this problem is to define your own databinding event and manually dispatching that event whenever you change the private property. You specify the event name as part of the [Bindable] metadata tag, and you’ll need to have your class extend EventDispatcher or one of its sub-classes to use the dispatchEvent method to dispatch your event.

There’s an event specifically defined for this purpose: PropertyChangeEvent.PROPERTY_CHANGE. This is the same event type that Flex uses internally when it generates the data binding code, so if it’s good enough for Flex it’s good enough for us. This class has a static createUpdateEvent method where you can supply the necessary properties – the object dispatching the event, the name of the property changed, the old value and the new value – and get back a PropertyChangeEvent object you can pass to dispatchEvent.

package {
  import flash.events.EventDispatcher;
  import mx.events.PropertyChangeEvent;
 
  public class User() {
 
    public function User(name:String):void {
      this._name = name;
    }
 
    private var _name:String;
 
    [Bindable(event="propertyChange")]
    public function get name() {
      return this._name;
    }
 
    public function addTitle(title:String):void {
      var oldName:String = this._name;
 
      this._name = title + " " + this._name;
 
      if (oldName !== this._name) {
        this.dispatchEvent(PropertyChangeEvent.createUpdateEvent(this, "name", oldName, this._name));
      }
    }
  }
}

Notice that I’m checking to see that the value of the name property really has changed before dispatching the event, which means the databinding mechanism isn’t unnecessarily invoked. In this case it wasn’t strictly necessary since we know that the property will always have changed, but it’s a good habit to get into.

This looks a bit messy though, and it’ll only get worse as you discover more places in your code where this property needs to be updated. What I do is add a private setPropertyName method that I can use whenever I want to change the properties value:

package {
  import flash.events.EventDispatcher;
  import mx.events.PropertyChangeEvent;
 
  public class User() {
 
    public function User(name:String):void {
      this._name = name;
    }
 
    private var _name:String;
 
    [Bindable(event="propertyChange")]
    public function get name() {
      return this._name;
    }
 
    private function setName(val:String):void {
      if (this._name !== val) {
        var oldName:String = this._name;
        this._name = val;
        this.dispatchEvent(PropertyChangeEvent.createUpdateEvent(this, "name", oldName, val));
      }
    }
 
    public function addTitle(title:String):void {
      this.setName(title + " " + this._name);
    }
  }
}

There, much better.

Using the PropertyChangeEvent class has another added benefit, which is that ArrayCollection objects (and possible others) listen out for this event on the items they contain and broadcast their own databinding events. If we’d used a custom Event class, the containing ArrayCollection wouldn’t have known anything had changed and any UI control bound to that ArrayCollection would not have been updated.

I’ve created a simple demonstration of this technique in action (view source) which you can also download.

Update

Having just ran the above example if debug mode I’ve noticed that you get a “warning: unable to bind to property ‘name’ on class ‘User’” in the console, which I thought was a bit strange since the example works just fine.

It turns out that Flex is trying to set up 2-way databinding so that any changes in the UI components are reflected in the binding source object (i.e. User). Because our User class is read-only, Flex cannot set up the reverse binding, and that’s where the warning is coming from.

The moral of the story is that you can ignore these warnings if they’re given on read-only properties.