The complete code of the RadioButtonGroupBox is presented in Listing 1. (Listings 1-13 can be downloaded from the online version of this article at http://coldfusion.sys-con.com.) See if you can discover the discrepancies between the listing and what we outlined in our snippets:

• We've added the text property, so we don't have to specify editorValue="value" in the item editor use case.
• We've made the properties text and value bindable by the "change" and "valueCommit" events; the dispatching of events is being done by an anonymous handler of the Event.CHANGE and setter of value correspondingly.
• We've allowed dynamic re-assigning of options by removing the existing dynamic RadioButtons prior to building the new ones from the options array.

Now let's test the itemRenderer/itemEditor scenario. Not that it's required, but we would prefer to lay out the radio buttons horizontally. Accordingly, we will create RadioButtonGroupHBox as a simple extension of the RadioButtonGroupHBox, taking care of the box's direction and adding a couple of padding pixels:

The screenshot of the test application RadioButtonGroupHBoxDemo is presented in Figure 2. As you may notice in Listing 4, we declared the entire DataGrid as editable, and marked the "status" column with rendererIsEditor="true":

Computed Column Color
Getting back to the DataGrid, we will look at controlling the styles of the DataGridColumn: color, backGroundcolor, font and so on. We'll focus on defining the styles in such a way that they are re-evaluated along with the data changes. Many times we meet business requirements that call the styles to be different from row to row. Supposedly, we need to highlight high paid employees ($50K or more) in red, otherwise the salary value is shown in green. One solution is to use the in-line itemRenderer:

<mx:DataGridColumn dataField="SALARY" textAlign="right">
   <mx:itemRenderer>
     <mx:Component>
       <mx:Label>
<mx:Script>
     <![CDATA[
       override protected function updateDisplayList(unscaledWidth: Number,
unscaledHeight:Number):void
       {
         super.updateDisplayList(unscaledWidth, unscaledHeight);
         if (data && listData) { // Check that we are in a List
       if (data.SALARY > 50000) {
         setStyle("color", "red");
       } else {
       setStyle("color", "green");
         }
         }
       }
       ]]>
          </mx:Script>
       </mx:Label>
     </mx:Component>
   </mx:itemRenderer>
</mx:DataGridColumn>

As a component base we've used Label, an immediate descendant of the UIComponent, because updateDisplayList(), an UIComponent method, would be out of reach for a standard DataGridItemRenderer based on UITextField. Alernatively, we could have achieved the same functionality with a more elegant binding expression syntax:

   <mx:DataGridColumn dataField="SALARY" textAlign="right">
    <mx:itemRenderer>
     <mx:Component>
      <mx:Label
color="{data.SALARY>50000?255*256*256:255*256}"
>
      </mx:Label>
     </mx:Component>
    </mx:itemRenderer>
   </mx:DataGridColumn>

Listing 5 presents the complete code of the sample application StandardDynamicStyleDemo. In addition to the DataGrid, we have thrown in "Increase" and "Decrease" buttons, which allow us to modify the salary values in increments of 10K. When you run a StandardSynamicStyleDemo, you will see the picture shown in Figure 3.

Computed Column Background
We can't apply the same technique for a background color, because Label does not support the backgroundColor style. In comparison, TextInput does and, although, we could have resorted to TextInput instead of Label, the mere absence of backgroundColor does not seem reason enough to give up a lightweight Label in favor of the heavier TextInput. After all, the beauty of Flex is that the framework is extensible. Our custom Label extended with backgroundColor support is shown in Listing 6.

We have defined not one, but two styles - backgroundAlpha and backgroundColor - and we use both values with graphics.beginFill() inside the overridden implementation of updateDisplayList(). Once we add the Label.as to theriabook.swc and register it within the component manifest XML, the DataGridColumn can be redefined as is done in the following snippet:

   <mx:DataGridColumn dataField="SALARY" textAlign="right">
    <mx:itemRenderer>
     <mx:Component>
      <fx:Label
backgroundColor="{data.SALARY>50000?255*256*256:255*256}"
      />
     </mx:Component>
    </mx:itemRenderer>
   </mx:DataGridColumn>

The difference between the above approach and the way we defined a similar DataGridColumn in Listing 5 is that now we compute backgroundColor instead of the color and use fx:Label instead of the Label from mx namespace. If you do the replacement and run the program, you'll see the picture as shown in Figure 4.

Despite the decent result, we still don't feel satisfied: employing the powerful mechanism of item renderers only for the purpose of managing styles seems to be design overkill. Let's speak our mind: we are after dynamic runtime styles, right? Wouldn't it be nice if we added an extra DataGridColumn attribute, called, say, runtimeStyles, where we could list all the styles and the abstract from the implementation. Here is an example:

   <fx:DataGridColumn dataField="SALARY" textAlign="right" formatString="money">
    <fx:runtimeStyles>
     <mx:Object
backgroundColor="{function(item:Object):String {return (item.SALARY>50000)?'red':'green';}}"
     />
    </fx:runtimeStyles>
   </fx:DataGridColumn>

This approach would let developers concentrate on the substance rather than on the process. Let's make it happen.