Monthly Archives: March, 2011

Using a DateField itemRenderer for a Spark DataGrid

Here is another simple example of using a custom itemRenderer in a Spark DataGrid. In this example, I am using an MX DateField component as an inline itemRenderer.
This DataGrid is also editable. Both columns “In Stock?” and “Availability Date” also have the property rendererIsEditor=”true”. This tells the DataGrid that the component specified as the itemRenderer is also the editor for this column. If you do not specify rendererIsEditor=”true”, then, updating the CheckBox or DateField will not actually affect the data. I am setting the selectedDate on the DateField via 2-way dataBinding:

selectedDate="@{data.availabilityDate}"

Here is the code that defines the column using the DateField itemRenderer:

<s:GridColumn headerText="Availability Date" dataField="availabilityDate"
     rendererIsEditable="true">
     <s:itemRenderer>
         <fx:Component>
             <s:GridItemRenderer>
                 <mx:DateField selectedDate="@{data.availabilityDate}"
                      horizontalCenter="0" verticalCenter="0"
                      width="90%"/>
             </s:GridItemRenderer>
         </fx:Component>
     </s:itemRenderer>
 </s:GridColumn>

Run the sample: DataGrid_DateFieldExample.swf

Source code: DataGrid_DateFieldExample.mxml

Using a Spark Form with Validators

In this example, I’ve created a very simple registration form using Flex 4.5’s Form component. To validate the form, I am using MX StringValidator and MX EmailValidator. There are no Spark validators available for the fields I have in my form. Validation does not get triggered in this example until you click on the ‘Submit’ button.

By default, the FormItem skin puts the error message to the right of your Form Item. However, this was causing the width of my Form to double. I didn’t want the size of my Form to change significantly, so, I reskinned my FormItem to remove the “indicatorDisplay” and “errorTextDisplay”. Instead, I’ve chosen to show the validation errors for all three fields in a separate Label component that sits at the top of this Form.

In my Style block, I point to this custom FormItem skin:

<fx:Style>
@namespace s “library://ns.adobe.com/flex/spark”;
@namespace mx “library://ns.adobe.com/flex/mx”;

s|FormItem {
skinClass: ClassReference(“FormValidatorItemSkin”)
}
</fx:Style>

Sample SWF: SparkFormValidatorExample.swf
Sample Code: SparkFormValidatorExample.mxml, FormValidatorItemSkin.mxml

Where is drag and drop in the Spark DataGrid?

Before you spend any significant amount of time trying to figure out what APIs are available for enabling drag and drop on the Spark DataGrid, I thought I’d put it out there that it will not be available in the first Hero release of the component.  In flash builder, I think you will get code hints for events like dragComplete, dragStart, dragEnter, dragOver, however, you won’t find the properties dragEnabled or dropEnabled.

I believe that the team plans to add drag and drop support in the next big release after Hero, but, features haven’t been set in stone and I certainly can’t promise anything.

For now, if you really need drag and drop in a Spark DataGrid, you are left writing your own. Sorry 😦  I was disappointed to hear the news too.

It’s a best practice to size a Spark DataGrid’s columns with a typicalItem

Coming from Flex 3, if I wanted to set the size of my DataGrid columns to ensure that all of my data was displayed correctly, I would either set column widths with explicit values or percentages. In Flex 4, explicit width columns is no longer the recommended way of figuring out the size of columns according to Spark DataGrid’s architect Hans Muller who schooled me when I mentioned the need to fix a bug that involved explicit width columns.

By default, a DataGrid will use the first item in its dataProvider to determine the size of each column. This may not be what you want. If you specify a typicalItem on the DataGrid, the columns will be large enough to fit this item. This item does not need to be a part of your dataProvider.

Specifying explicit column widths can be problematic because the width can be invalidated by  a host of factors: implicit renderer changes, e.g. due to inherited styles, explicit renderer changes, margin/padding and other layout configuration changes, as well as text and text format localizations.  For all of these reasons, using the typicalItem is better.

In the following example, I have two DataGrids with the same data and columns. The first one specifies a typicalItem where the data includes the longest strings that I want to display in my columns. The second DataGrid uses no typicalItem and therefore sizes its columns using the first item of the dataProvider.

Sample application: TypicalItem_DataGrid_Example.swf

Sample MXML: TypicalItem_DataGrid_Example.mxml

If you change your typicalItem, you will need to call invalidateTypicalItem() notifying the DataGrid of this change.

Note, almost all of this information was compiled from picking the brain of Hans Muller, I hope I’ve accurately represented his thinking.