Thursday, November 29, 2007

Use ArrayCollection available in HTTPService result with caution

Please refer to this and this bug report .

Both of them speak about data editing/update not getting propagated properly through a ArrayCollection. The samples are using the ArrayCollection available from the HTTPService result directly. The HTTPService is creating the ArrayCollection first and then updating its source Array with items. The Array object doesn't dispatch any events when it is updated with new items. Due to this ArrayCollection has no way of adding event listeners for property changes to the items added later on. Hence the changes are detected only for the items present at the time of creation of ArrayCollection which happens to be 2 items.

If one desire to use the HTTP result as dataProvider and expects data updates to get properly propagated they need to create a new ArrayCollection using the source of the default ArrayCollection present in the HTTP result.

data_provider = new ArrayCollection(ArrayCollection(srv.lastResult.data.result).source);

where srv is the HTTPService. If data_provider is already a ArrayCollection then we can just modify the source as follows

data_provider.source = ArrayCollection(srv.lastResult.data.result).source;

This bug exists in Flex 2 and may not be fixed in Flex 3 as the current bug status is deffered! The source is available here and data getting loaded here.

Customizing grouping using GroupingField.groupingFunction in GroupingCollection

It is possible to generate custom groups using groupingFunction property of GroupingField. Take a look at the following sample. By choosing different options from "Choose age range" users can view the same data in different groups.

The sample uses fictitious data of web site visitors by age and location. The example uses COUNT summary option to show how many visitors exist in each group.

The only thing to remember while writing a groupingFunction is that the return value should not change the sorting order being used for the dataField. Another way to put it is, the groupingFunction should return group names in a sorted order only. It shouldnot return group names in a random fashion.

The source can be found here.

Monday, November 19, 2007

XMLList, HierarchicalData and AdvancedDataGrid

Using a XMLList as source for GroupingCollection or HierarchicalData is a bit tricky. The trickiness comes from the fact that there are two ways to specify values for a XML node. One as attributes and second as child nodes. Depending on which way values are specified we need to set properties differently to get the desired display in ADG. For XMLList data type HierarchicalData treats the child nodes of a node to be children of the parent node by default. Specifying values as attributes:


<Parent field1="valueA" field2="valueB" >
 <Child1 field1="value1" field2="value1b" />
 <Child2 field1="value2" field2="value2b" />
 <Child3 field1="value3" field2="value3b" />
</Parent>

Here Child1, Child2 and Child3 would be recognized as children of Parent node. Specifying values as sub nodes:


<Parent>
    <field1>valueA</field1>
    <field2>valueB</field2>

   <subnodes>
    <Child1>
     <field1>value1</field1>
     <field2>value1b</field2>
    </Child1>
    <Child2>
     <field1>value2</field1>
     <field2>value2b</field2>
    </Child2>
    <Child3>
     <field1>value3</field1>
     <field2>value3b</field2>
    </Child3>
   </subnodes>
</Parent>

If above data is set as source to HierarchicalData it would treat field1, field2 and subnodes as children of Parent node, which is not correct. To tell HierarchicalData to use only the nodes under subnodes as children set HierarchicalData.childrenField to "subnodes".

The same rules apply when GroupingCollection (which is derived from HierarchicalData) is used to group flat data.

Suppose following data is used as input to GroupingCollection and grouped on Region


<Row>
    <Region>Southwest</Region>
    <Territory>Arizona</Territory>
    <Territory_Rep>Barbara Jennings</Territory_Rep>
    <Actual>38865</Actual>
    <Estimate>40000</Estimate>
</Row>

<Row>
    <Region>Southwest</Region>
    <Territory>trials</Territory>
    <Territory_Rep>Dana Binn</Territory_Rep>
    <Actual>4000</Actual>
    <Estimate>5000</Estimate>
</Row>
 
<Row>
    <Region>SouthEast</Region>
    <Territory>Central California</Territory>
    <Territory_Rep>Joe Smith</Territory_Rep>
    <Actual>5000</Actual>
    <Estimate>6000</Estimate>
</Row>

<Row>
   <Region>Southwest</Region>
   <Territory>Nevada</Territory>
   <Territory_Rep>Bethany Pittman</Territory_Rep>
   <Actual>1000</Actual>
   <Estimate>2000</Estimate>
</Row>

The result won't get displayed because the base HierarchicalData would treat <Region>, <Territory> etc nodes also as children of Row. To get proper display we need to set GroupingCollection.childrenField="abc" or some non existent node name. This would cause HierarchicalData to report that no children exist for the Row.

Friday, November 9, 2007

Smart column width based on data displayed (Part One: No code yet)

From the poll conducted I find that many users want Smart column width based on data displayed in DG/ADG.

I hope people requesting this feature know that it is a CPU intensive process to go over all the items in the dataProvider to find out maximum width required for all the columns. If the number of visible columns is more it would take even more time to compute the values and layout the columns.

If a labelFunction is being used at DG or DGColumn level and custom styles have been used on a column for fontSize for example, it complicates the computation even more.

When the data is being paged from a server it is not possible to compute the smart width at all without requesting all the data from the server, which is never desirable.

Keeping these things in mind I feel it makes sense to have a flag on individaul DGcolumn (apart from one on the DG itself) to control the computation of smart width. If the flag is true width is computed and false would use the normal way of determining the column width.

Thoughts?

Thursday, November 8, 2007

Generating summary for flat data using GroupingCollection

This example shows how GroupingCollection can be used to generate summary data for flat data and AdvancedDataGrid can be used to display the result.

The trick (or dirty work around if you like to call it so) is to generate a single dummy group using a invalid grouping field. The summary we require is specified as usual using the SummaryRow and SummaryField.

When this GroupingCollection is fed to ADG.dataProvider it would try to display in a tree view. By setting the HierarchicalCollectionView.showRoot flag to false to avoid displaying the single group parent.

By specifying the default ADGItemRenderer as ADG.groupItemRenderer we can prevent the group icons from getting displayed.

The source is here.

Please note I have not tested this example extensively. So some bug fixes may be required before it can be used in production.

Friday, November 2, 2007

Customizing Group label fields when using GroupingCollection

By using the ADG.groupLabelFunction property one can customize the group label displayed for the group nodes. The following example shows how children count can be displayed as part of the group label when the group is closed. The source can be found here.