From Farata Systems blog

Adobe Flex framework contains a pretty impressive library of the off-the-shelf controls, which can fit the bill for many of the Rich Internet Applications needs. And yet, it is just the tip of the iceberg, because Flex enables you to create, combine and/or extend existing components with a simplicity and elegance hardly ever offered by other GUI development systems.  In this article I’ll show you how to start extending a standard ComboBox component, which is  a combination of edit field, button and a dropdown list. We will be customizing the API and adding some new functionality, making our ComboBox  a bit handier than a standard one.

A typical task, while working with a standard ComboBox, is to programmatically select a specific value. Suppose our ComboBox is populated with array of states:

    private var usStates:Array=[
        {label:"New York", data:"NY"},
        {label:"Colorado", data:"CO"},
        {label:"Texas", data:"TX"}                
    ];
    .   .   .   .   .   .   .   .
    <mx:ComboBox id="cbx_states" dataProvider="{usStates}"/>

To programmatically select Texas (to the visible portion of the ComboBox), you can write the following index-fetching loop, comparing val against the label of each element of dataProvider:

var val:String;

val = ’Texas’ ;
for (var i: int = 0; i < cbx.dataProdider.length; i++) {
  if ( val == cbx_states.dataProvider[i].label) {
    cbx_states.selectedIndex = i;
    break;
  }    
}

Alternatively, you could look up the data of dataProvider’s elements :

var val:String;

val = 'TX'  ;
for (var i: int = 0; i < cbx.dataProdider.length; i++) {
  if ( val == cbx.dataProvider[i].data) {
    cbx_states.selectedIndex = i;
    break;
  }    
}

Either way these index-fetching loops will clutter the application code instead of simple cbx_states.value=‘Texas’. On top of that, index-fetching via data is often unapplicable. Consider real-life ComboBox records coming from databases, messages etc. We can’t “mandate” to these data sources to contain  data field in the relevant record sets. And while the  standard ComboBox provides the labelField property, allowing to draw a label value from an arbitrary property, there is not a dataField property, which would allow a similar flexibility for data.

So far we’ve identified areas for improvement in selecting or setting value. Now let’s look at the opposite opperations. Standard ComboBox offers the properties  selectedIndex and selectedItem. When a ComboBox is populated with strings, selectedItem  returns selected string (or null if nothing is selected). If it’s populated with objects, selectedItem references selected  object ( or contains null):

<mx:Application xmlns:mx=http://www.adobe.com/2006/mxml creationComplete="onCreationComplete()">

private function onCreationComplete():void {
    mx.control.Alert.show(cbx_states.selectedItem.label); // displays 'New York'
    cbx_states.selectedIndex=-1;             //Removes initial selection
    mx.control.Alert.show(cbx_states.selectedItem); // “displays” null
}
.  .  .  .  .  .  .  .  .
</mx:Application>
    
Listing 1 Using selectedItem and selectedIndex properties

But wait, there is also a read-only value property:  if a selected object has something in the data property, value refers to  data, otherwise value refers to  the label:

    mx.control.Alert.show(cbx_states.value); // displays 'NY'

As you can see value does a half of the job: it shields us from selectedItem/ selectedIndex. What we miss is another half and in the following sections we will turn value into a read-write property. That will forever absolve us from index-fetching loops to modify the ComboBox selection.

We will also introduce the dataField property which will support any arbitrary property in place of  data, depending on a  specific ComboBox instance

Making the  value Property Writeable
    
Let’s start with upgrading  the value to the first class writeable property. The simplest way to do this is by extending the original ComboBox so that derived class provides a special setter for the value property. The setter attempts to match the value with either data or label properties of the dataProvider. Once a match is found, it modifies the selectedIndex which should cause the ComboBox to select the matching object:
 
<?xml version="1.0" encoding="utf-8"?>
<mx:ComboBox xmlns:mx="http://www.adobe.com/2006/mxml"  >
<mx:Script>
<![CDATA[
    public function set value(val:Object)  : void {
        if ( val != null ) {
            for (var i : int = 0; i < dataProvider.length; i++) {
                if ( val == dataProvider[i].data || val == dataProvider[i].label) {
                    selectedIndex = i;
                    return;
        }    }    }
        selectedIndex = -1;
    }
]]>
</mx:Script>
</mx:ComboBox>

Listing 2. ComboBox.mxml - Making the value property writeable

If the ComboBox.mxml is located under the com/theriabook/controls, its test application can look as in  Listing 3 below.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns="*" xmlns:lib="com.theriabook.controls.*">
    <mx:ArrayCollection id="comboData" >
        <mx:Array>
            <mx:Object label="New York" data="NY"/>
            <mx:Object label="Connecticut" data="CT"/>
            <mx:Object label="Illinois" data="IL"/>
        </mx:Array>
    </mx:ArrayCollection>
    <mx:Label text="Current bound value is '{cbx_1.value}' " />
    <lib:ComboBox id="cbx_1" value="IL" width="150" dataProvider="{comboData}"/>
</mx:Application>


Listing 3. Using our new ComboBox

Run this  application,  and you’ll see the ComboBox displaying the value New York… while we  would expect Illinois. We forgot about the order in which objects’ properties (cbx_1) get initialized. In particular, the  value property is initialized before the dataProvider. And, since during dataProvider initialization ComboBox, by default, selects the first item, the work performed by our value setter is wasted. You can prove the point by just trading places of value and dataProvider in the above application code.

Should we rely on the order of attributes in MXML components? Apparently not. Especially when Flex offers an excellent mechanism to coordinate the updates to multiple properties of the control – the commitProperties() method.

Here is how it works: whenever you need to modify a property raise some indicator, store the value in the temporary variable and call invalidateProperties(), like in the following snippet:

    private var candidateValue:Object;
    private var valueDirty:Boolean = false;

    public function set value(val:Object)  : void {
        candidateValue = val;
        valueDirty = true;        
        invalidateProperties();
    }

In response to invalidateProperties() Flex will schedule a call of commitProperties() for a later execution,  so that all property changes deferred in the above manner can be consolidated in a single place and in the pre-determined order:

    override protected function commitProperties():void {
        super.commitProperties();

        if (dataProviderDirty)    {
            super.dataProvider = candidateDataProvider;
            dataProviderDirty = false;
        }

        if (valueDirty) {
            applyValue(candidateValue);
            valueDirty = false;
        }            
        }

Aside of co-ordinating updates to different properties, this coding pattern helps to avoid multiple updates to the same property and, in general, allows setter methods to return faster, improving the overall performance of the control. The entire code of our “value-aware” ComboBox is presented in Listing 4:

<?xml version="1.0" encoding="utf-8"?>
<mx:ComboBox xmlns:mx="http://www.adobe.com/2006/mxml" >
<mx:Script>
    <![CDATA[
    
    private var candidateValue:Object;
    private var valueDirty:Boolean = false;
    private var candidateDataProvider:Object;
    private var dataProviderDirty:Boolean = false;
    
    private function applyValue(val:Object):void {
        if ((val != null) && (dataProvider != null)) {
                
            for (var i : int = 0; i < dataProvider.length; i++) {
                if ( val == dataProvider[i].data || val == dataProvider[i].label) {
                    selectedIndex = i;
                    return;
        }    }    }
        selectedIndex = -1;
    }    

    public function set value(val:Object)  : void {
        candidateValue = val;
        valueDirty = true;        
        invalidateProperties();
    }
    override public function set dataProvider(value:Object):void {
        candidateDataProvider = value;
        dataProviderDirty = true;
        invalidateProperties();
    }

    override protected function commitProperties():void {
        super.commitProperties();

        if (dataProviderDirty)    {
            super.dataProvider = candidateDataProvider;
            dataProviderDirty = false;
        }

        if (valueDirty) {
            applyValue(candidateValue);
            valueDirty = false;
        }            
    }        
    ]]>
</mx:Script>
</mx:ComboBox>

 
Listing 4. The value-aware ComboBox

Now everything works as expected. The screenshot of the running application is presented below:



Figure 1. The “value-aware" ComboBox in action

If you change the ComboBox selection, the top label, which initially contains Current bound value is “IL” will change accordingly. No miracles here, a regular Flex data binding one would say. Indeed, good things are easy to take for granted. Still, we have not provided any binding declarations or binding code in our ComboBox. So why does it work? It works because the original Flex definition of value getter ComboBox has already been marked with metadata tag [“Bindable”], which makes the property bindable (you do not have to have a setter to be bindable):

[Bindable("change")]
[Bindable("valueCommitted")]

But wait, you may say, these binding definitions indicate  that data modifications bound to value property get triggered in response to events change or valueCommitted. Yet our value setter does not contain a single  dispatchEvent call. Where is the catch? Events are dispatched inside the code that assigns  selectedIndex. This assignment results in invocation of selectedIndex setter, which ultimately dispatches events.