More on Customizing the DataGridColumn
We'll put our DataGridColumn in the dataGridClasses subfolder as a sign of our respect for the well-thought-out directory structure of the Flex framework:

As mentioned above, the "dirty" job of locating and assigning the proper label function has been delegated to the helper class FormattingManager. This class, presented in Listing 4, should be put in our theriabook project.

Tada! And the winner is...the developer. Once we add theriabook.swc (with DataGrid, DataGridColumn, and FormattingManager) to the library path, the application code gets reduced to Listing 5.

Improving FormattingManager
In the previous examples we've used SwitchSymbolFormatter for both phone and ssn formatting. As soon as we start formatting numbers or currency values, it's natural to use NumberFormatter or CurrencyFormatter - descendants of mx.formatters.Formatter. In fact, Flex offers a dedicated formatter even for the phone formatting.

While SwitchSymbolFormatter derives from Object, all the rest of the formatters descend from Formatter. By encapsulating this specific of SwitchSymbolFormatter in the custom class MaskFormatter we'll help ourselves in basing the next version of FormattingManager entirely on Formatters as in Listing 6.

Look how this MaskFormatter simplifies our FormattingManager: we can replace all the private methods with an anonymous function, as shown in Listing 7. Please note that the reference to the appropriate formatter is preserved with the closure.

The testing application FormatStringDemo is in Listing 8. If you run it, the DataGrid dg will be formatted as shown in Figure 4:

Let's focus on the hard-coding that we allowed in case of the money value:

     case "money":
        formatter = new CurrencyFormatter();
        CurrencyFormatter(formatter).precision=2;
        break;

This hard-coding reflects, perhaps, the most "popular" case. But what if we want to have the full advantage of the properties of the corresponding formatter, such as precision, in case of CurrencyFormatter? To address these cases we're going to introduce one more fx:DataGridColumn property - formatData. Here's how it will be used in the application MXML:

    <fx:DataGridColumn dataField="SALARY" >
      <fx:formatData>
        <mx:Object formatString="money" precision="0"/>
      </fx:formatData>
    </fx:DataGridColumn>

The elegance of MXML lets us implement this extension with just a few lines of extra code in com.theriabook.controls.dataGridClasses.DataGridColumn:

    public function set formatData(fd :Object) : void{
      FormattingManager.setFormat(this, fd);
    }

Then, to accommodate the change on the FormattingManager side, we'll iterate through all the properties of the formatData object and attempt to assign them to the appropriate properties of the formatter with an emphasis on the word appropriate. The MXML compiler isn't going to help us check the properties of the unsealed <mx:Object> against the properties of the formatter. Accordingly, to protect ourselves from the no-such-property-exceptions, we surround property assignments with try/catch:

    public static function setFormat(
        dgc:mx.controls.dataGridClasses.DataGridColumn,         formatData:Object
    ):void {
      . . . . .
      if (!(formatData is String)) {
        for (var property:String in formatData) {
        try {
            formatter[property] = formatData[property];
          } catch (err:Error) {
            // Property does not match formatter type
          }
        }
      }
      . . . . .
    }

The complete listing of renewed FormattingManager is in Listing 9. While maintaining your own framework, you would transform this class to accommodate your requirements

Finally, Listing 10 has the sample application to test our changes, FormatDataDemo.

When you run the application it will produce the DataGrid shown in Figure 5.

We'll continue beefing up our custom DataGridColumn after a short detour into CheckBox and RadioButton controls.

CheckBox as a Drop-In Renderer
As we warned the reader at the beginning of this article, DataGrids rarely come alone. In this section we're going to suggest customizimg the CheckBox, which will help us illustrate custom DataGridColumns from a different perspective.

The state of a CheckBox control is managed by the Boolean property selected. At the same time, many business systems use either Y/N or, sometimes, 0/1 flags. As a result, translating business-specific values into selected and vice versa burdens the application code. Listing 11 presents the custom CheckBox, which supports application-specific on and off values along with the current value.

So, using this CheckBox, we could have written:

<fx:CheckBox value="Y" onValue="Y" offValue="N" />

to have selected CheckBox, or

<fx:CheckBox value="N" onValue="Y" offValue="N" />

to set selected to false.

DataGridColumn as ItemRenderer's Knowledge Base
Now let's get back to the DataGrid world. What if we wanted to use our CheckBox as the DataGrid item renderer? Here's the suggested use case example:

<fx:DataGridColumn dataField="BENE_DAY_CARE"
       itemRenderer="com.theriabook.controls.CheckBox" >
    </fx:DataGridColumn>

Obviously, we need to modify the CheckBox more to take care of the value within the data setter:

    override public function set data(item:Object):void
    {
      super.data = item;
      if( item!=null ) {
        value = item[DataGridListData(listData).dataField];
      }
    }

But how will we communicate the offValue and onValue properties to our CheckBox-turned-itemRenderer? Ideally, we would need something like:

    <fx:DataGridColumn dataField="BENE_DAY_CARE"
    itemRenderer="com.theriabook.controls.CheckBox" >
      <fx:extendedProperties>
        <mx:Object onValue="Y" offValue="N" />
      </fx:extendedProperties>
    </fx:DataGridColumn>