Flex creators thought of this in advance. An object referenced by itemRenderer is not a CheckBox but rather an instance of mx.core.ClassFactory wrapped around the CheckBox. The mechanism of mx.core.ClassFactory allows Flex to generate instances of another class - in our case com.theriabook.controls.CheckBox. Importantly, each instance created by the factory is assigned identical properties borrowed from the properties property of the factory object. Accordingly, all we have to do is pass the value of the extendedProperties as the properties of the itemRenderer as shown in Listings 12.

The test application, ExtendedPropertiesDemo, is in Listing 13. When you run it, it produces the data grid shown in Figure 6.

We should have mentioned the alternative run-of-the-mill approach with inline itemRenderer. It's in Listing 14.

Arguably, the extendedProperties approach is more efficient, since it absolves MXML of generating an extra nested class (mx:Component) for each column of this kind and we've introduced you to yet another mean of customizing a DataGridColumn. We'll continue building on top of it in the following sections.

Nitpicking CheckBox
There are some additional remarks that we ought to add to our CheckBox implementation at this point. The first one is related to the horizontal alignment of the CheckBox. Instincts tell us that label-free checkbox should be centered in the column, rather than stuck in the leftmost position. At first, you may try the textAlign style of the DataGridColumn to no avail. Then you may resort to another run-of-the-mill approach to center the Checkbox by putting it inside a container, such as HBox. Here's the performance-based advice endorsed by Flex Framework engineers: avoid containers inside the datagrid cell at any reasonable cost. In particular, instead of using HBox, why not sub-class the CheckBox and override the updateDisplayList method? It gets quite natural once you've stepped on this path, so we'll add the code shown below to our CheckBox (the complete code of com.theriabook.controls.CheckBox is in Listing 15):

   import mx.core.mx_internal;
   use namespace mx_internal;
    . . . .
     override protected function updateDisplayList(
      unscaledWidth:Number, unscaledHeight:Number):void
     {
      super.updateDisplayList(unscaledWidth, unscaledHeight);
      if (currentIcon) {
       var style:String = getStyle("textAlign");
       if ((!label) && (style=="center") ) {
        currentIcon.x = (unscaledWidth - currentIcon.measuredWidth)/2;
       }
      }
   }

Please note the use of namespace mx_internal. It's required so the reference to currentIcon visualizes the checkbox picture, since the currentIcon, the child of the original CheckBox, is originally scoped as mx_internal.

Now we modify the testing application to include textAlign="center":

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

And, when we run it, all checkboxes are in their proper places:

The second nitpicking point is related to undefined as the possible value of a property. Under our current business scenario, we can assume that some of the employees are not eligible for day care benefits, and relevant items in the dataProvider's collection are lacking BENE_DAY_CARE property, which can be expressed as item.BENE_DAY_CARE=="undefined" for dynamic items. (See Figure 7)

Does it make sense to show checkboxes for non-eligible employees? Perhaps, it doesn't. In these cases we would make currentIcon invisible. You may select a different approach and show a fuzzy checkbox image instead, but that is beside the point. The following modification of updateDisplayList does the job of removing checkBox when the value is undefined:

override protected function updateDisplayList(unscaledWidth:Number,unscaledHeight:Number):void
    {

      super.updateDisplayList(unscaledWidth, unscaledHeight);
      if (currentIcon) {
        var style:String = getStyle("textAlign");
        if ((!label) && (style=="center") ) {
          currentIcon.x = (unscaledWidth - currentIcon.measuredWidth)/2;
        }
        currentIcon.visible = (_value!=undefined);
      }
    }

To accommodate this change we also have to loosen up the class definitions for value as shown in Listing 15, where we change Object to undefined.

Next and probably the most important fix is that our CheckBoxes have been silenced. Try to click on one, scroll the row out of view, and scroll it back in. The checkbox doesn't retain your selection and it shouldn't: we have never communicated the change to the underlying data. To remedy this situation we'll add the constructor method, where we'd start listening on the "change" event; once an event is intercepted we'll modify the data item with the CheckBox value. That, in turn, will result in either onValue or offValue as per our value getter:

    public function CheckBox() {
      super();
      addEventListener(Event.CHANGE,
        function(event:Event):void{
          if (listData) {
            data[DataGridListData(listData).dataField] = value;
          }
        }
      );
    }

The complete code for the second version of CheckBox is in Listing 15.

Next comes the test application in Listing 16. We've added the "Revoke day care benefit" button, which makes DAY_CARE_BENE undefined on the currently selected DataGrid item. We also had to notify the collection with the itemUpdated() call.

When you run the application, you'll see that checkboxes retain the selection after scrolling out and back into view. If you click the "Revoke" button for the first two rows, you're going to see a picture similar to Figure 8.

The last CheckBox fix will come in handy once you declare the DataGrid editable. Why declare it editable in the first place if we seem to be editing the DataGrid already? Let's not forget that the only field we've edited so far is the checkbox BENE_DAY_CARE. Should you also decide to allow editing the text fields you'd have to change the definition of the DataGrid as shown in bold in this snippet:

    <fx:DataGrid id="dg" creationComplete="dg.fill();dg.selectedIndex=0;" editable="true"
     destination="com_theriabook_composition_EmployeeDAO" method="getEmployees" >

But once you do that, a click on our beautiful checkbox would turn it into default editor - TextInput, quite like in a Cinderella story. To make the miracle last, you'd declare that your renderer is good to go as an editor as well:

    <fx:DataGridColumn dataField="BENE_DAY_CARE" textAlign="center"
      itemRenderer="com.theriabook.controls.CheckBox" rendererIsEditor="true">
      . . .
    </fx:DataGrid>

By default, DataGrid reads the text property of the item editor. You can nominate a different property via editorDataField (in our case that would be value). Alternatively, and what will help us later, you can "upgrade" the checkbox to carry the text property itself:

    public function set text(val:String) :void {
      value = val;
    }

    public function get text():* {
      return value;
    }

Summary
While DataGrid is a powerful component right off-the-shelf, but the fact that it's truly extendable can substantially increase its usability. In the next part of this article, we'll continue experimenting with the DataGrid by using radio buttons as renderers and introduce computed columns.