Page 1 of 3   next page »

In any GUI tool, one of the most popular components is the one that shows data in a table format like JTable in Java or Datawindow in PowerBuilder. The Adobe Flex 2 version of such a component is called DataGrid. In any UI framework, the robustness of such a component depends on formatting and validating utilities as well as a whole suite of data input controls: CheckBoxes, ComboBoxes, RadioButtons, all sorts of Inputs, Masks, and so on. Using theatrical terminology, the role of the king is played by his entourage. Practically speaking, touching up the DataGrid is touching up a large portion of the Flex framework.

We'll start by upgrading the standard DataGrid to a "destination-aware" control capable of populating itself. Next, we'll look at the task of formatting DataGrid columns and that would naturally lead us to a hidden treasury of the Flex DataGrid - the DataGridColumn, which, once you start treating it like a companion rather than a dull element of MXML syntax, can help you do truly amazing things.

After setting the stage for the DataGrid's satellite controls, we'll lead you through making a professional library with a component manifest file and namespace declaration that supports flexible mappings of your custom tags to the required hierarchy of implementation classes.

Making DataGird Destination-Aware
Introducing Flex remoting substantially increased the size of our application code. Imagine a real-world application with two-dozen different ComboBoxes or DataGrids. If we put all the relevant RemoteObjects in a single application file it will become unmanageable in no time. For similar reasons, any decent sized application is usually partitioned into different files.

As far as partitioning goes, there's a compelling argument to encapsulate instantiation and interoperation with RemoteObject inside the visual component, making it a destination-aware component, if you will. Embedding a Remote Object directly into the DataGrid will make it fully autonomous and reusable. This design approach sets application business logic free from low-level details like mundane remoting.

The concept of destination-aware controls eliminates the tedious effort required to populate your controls with Remoting or DataServices-based data. Here's how an MXML application with a destination-aware DataGrid might look if we apply the familiar remoting destination com_theriabook_composition_EmployeeDAO:

<!-- DestinationAwareDataGridExDemo.mxml-->
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx=http://www.adobe.com/2006/mxml layout="vertical"
        xmlns:fx="com.theriabook.controls.*">
        <fx:DataGridEx id="dg"
     destination="com_theriabook_composition_EmployeeDAO"
     method="getEmployees" creationComplete="dg.fill()"/>
</mx:Application>

In Listing 1 we have sub-classed the standard Flex DataGrid.

The data are coming from a server-side database with the help of a Java object called EmployeeDAO. If we run the application, our screen will show the grid of employee records in its default formatting:. (See Figure 1).

Formatting with labelFunction
We have just looked at the default data formatting provided by DataGrid out-of-the-box. The easiest way to improve column formatting is by supplying a labelFunction for each column that requires extra attention:

     <mx:DataGridColumn dataField="PHONE" labelFunction="phoneLabelFunction" />

Once the labelFunction is declared it automatically gets called by the DataGrid, which supplies the appropriate data item plus information about the column so that you can technically apply one function to more than one column. As far as the formatting techniques themselves, Flex offers plenty of pre-defined formatters, which can be used out-of-the-box or customized to your specific needs. For instance, to format Social Security numbers (SS_NUMBER), we could have used mx.formatters.SwitchSymbolFormatter to create the following function:

    import mx.formatters.SwitchSymbolFormatter;
    private var sf:SwitchSymbolFormatter;
    private function ssnLabelFunction(item:Object, column:DataGridColumn):String {
      if (!sf) {
        sf = new SwitchSymbolFormatter();
      }
      return sf.formatValue("###-##-####", item["SS_NUMBER"]);
      }

Then inside the DataGridColumn we can mention this function name:

     <mx:DataGridColumn dataField="SS_NUMBER" labelFunction="ssnLabelFunction" />

Similarly, in Listing 2 we can apply the same technique to the PHONE field setting the formatString to (###)###-####.

Figure 2 shows how our formatting looks on the screen.

Formatting with Extended DataGridColumn
The labelFunction formatting does the job. The price tag is hard-coding labelFunction(s) names in the DataGridColumn definitions. If you packaged a set of label functions in the class mydomain.LabelFunction your column definitions might look like this:

<mx:DataGridColumn    dataField="PHONE" labelFunction="mydomain.LabelFunctions.phone" />
<mx:DataGridColumn    dataField="SS_NUMBER" labelFunction=" mydomain.LabelFunctions.ssn" />

A more pragmatic approach is to provide the formatString as an extra attribute to the DataGridColumn and have it encapsulate the implementation details. We're talking of the following alternative:

<fx:DataGridColumn    dataField="PHONE" formatString="phone" />
<fx:DataGridColumn    dataField="SS_NUMBER" formatString="ssn" />

Implementing such syntax is within arm's reach. We just have to extend - well, not the arm, but the DataGridColumn so that instead of mx:DataGridColumn we would use our, say, fx:DataGridColumn. The mx.controls.dataGridClasses.DataGridColumn is just a respository of styles and properties to be used by the DataGrid. In the Flex class hierarchy it merely extends CSSStyleDeclaration. Nothing prevents us from extending it further and adding an extra attribute. In the case of formatString the setter function will delegate assigning the labelFunction to the helper FormattingManager:

    public class DataGridColumn extends mx.controls.dataGridClasses.DataGridColumn {
      public function set formatString( fs:String ) : void{
        FormattingManager.setFormat(this, fs);
      }
    }

Wait a minute, where did the FormattingManager come from? We'll get to the implementation of this class later. At this point, we have to eliminate the possible naming collision between our to-be-made DataGridColumn and the standard mx.controls.dataGridClasses.DataGridColumn.

Introducing the Component Manifest File
Up till now we've been keeping folders with classes of our custom components under the folder of application MXML files. To reference these components we've been declaring namespaces pointing to some hard-coded, albeit relative paths, such as xmlns:lib="com.theriabook.controls.*" or xmlns="*". The problem with this approach is that these namespaces point to one folder at a time. As a result, we either end up with multiple custom name spaces or we have a wild mix of components in one folder.

To break the spell and abstract the namespace from the exact file location we need to use the component manifest file. Component manifest is an XML file that allows mapping of component names to the implementing classes. Below is the example of component manifest, which combines our custom DataGrid and DataGridColumn located in different folders:

<?xml version="1.0"?>
<componentPackage>
    <component id="DataGrid" class="com.theriabook.controls.DataGrid"/>
    <component id="DataGridColumn"
    class="com.theriabook.controls.dataGridClasses.DataGridColumn"/>
</componentPackage>

To benefit from using this component manifest you have to compile your components with the compc or use the Flex Library project. To be more specific, you have to instruct compc to select the URL that your application can use later in place of the hard-coded folder in the xmlns declaration. So we'll create a new FlexLibrary project - theriabook, where we'll put the theriabook-manifest.xml containing the XML above and set the relevant project properties, as shown in Figure 3.

Now we can move DataGrid from our application project to theriabook and replace xmlns:fx="com.theriabook.controls" with xmlns:fx="http://www.theriabook.com/2006" provided that our application project will include a reference to theriabook.swc. As a result our application will reference fx:DataGrid and fx:DataGridColumn irrespective to their physical location.

Having done that, let's get back to the custom DataGridColumn.

Page 1 of 3   next page »