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:

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:

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:

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:

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:

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:

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.

Dr. Victor Rasputnis is a Managing Principal of Farata Systems. He's responsible for providing architectural design, implementation management and mentoring to companies migrating to XML Internet technologies. He holds a PhD in computer science from the Moscow Institute of Robotics. You can reach him at vrasputnis@faratasystems.com

Yakov Fain is a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay. He wrote a thousand blogs (http://yakovfain.com) and several books about software development. Yakov authored and co-authored such books as "Angular 2 Development with TypeScript", "Java 24-Hour Trainer", and "Enterprise Web Development". His Twitter tag is @yfain

Anatole Tartakovsky is a Managing Principal of Farata Systems. He's responsible for creation of frameworks and reusable components. Anatole authored number of books and articles on AJAX, XML, Internet and client-server technologies. He holds an MS in mathematics. You can reach him at atartakovsky@faratasystems.com

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.