Ben Forta

Last week I showed how to use the new Flex 3 AdvancedDataGrid to group data (that example used ColdFusion data returned as a query, although the example could also be applied to other back-ends, too). Grouping creates a tree within the data grid, so that groups of data may be collapsed and expanded as needed.
Now let’s take the example a step further, this time adding summary data. For example, suppose you were displaying sales orders, grouped by customer and then by order number. When collapsed the tree would list all customers, but no details. When a customer was expanded the tree would list all orders for that customer, but no details. When a specific order was expanded, then the details for that order would be displayed. That’s how basic grouping works.
But what if you wanted to show summary data for groups? For example, customer rows could show total of all orders for that customer, regardless of how many orders there were, and whether or not the customer group is expanded or collapsed. And then order rows could show order totals. You get the idea. And yes, this functionality is built in to the Flex 3 AdvancedDataGrid.
As before, this is a ColdFusion powered example using the default database tables that come with ColdFusion 8. Here is the simple CFC method which just returns several columns from three tables:




SELECT orders.orderid,
artname, orderitems.price,
customerlastname || ', ' || customerfirstname AS customer
FROM orders, orderitems, art
WHERE orders.orderid=orderitems.orderid
AND orderitems.artid=art.artid
ORDER BY customer, orders.orderid




I saved this component as art.cfc in a folder named test beneath the web root. You can save it wherever you like, but of course you’ll need to adjust the path in the MXML accordingly. (If you tried the previous example, you could just add this getOrders() method to the existing CFC.
Now for the MXML:














































I am not going to explain the basics of invoking the CFC method via , populating the GroupingCollection, and refreshing the . That was covered in the previous post. Rather, let’s look at what has changed.
First of all, to make it easier to expand and collapse the tree within the , I added a containing two buttons, one to expand all rows and one to collapse all rows.
As before, is used to define the grouping levels. In the previous example a single level of grouping was used, here two are used (to group by customer, and then by order id within customer). In the previous example had no child tags, because simple grouping was used. Here, has been added to each so as to summarize data by those groups. can display summary data at the group level, as well as at the first or last member within the group, as specified by the “summaryPlacement” attribute. A contains one or more fields to be summarized. Here a single is used for each to “SUM” the total of that group, putting the result in a column named “Total”. The “operation” attribute specifies the summary to be performed, and AVG, COUNT, MAX, MIN, and SUM are all built-in and ready for use. It is also possible to perform your own calculations, specifying an ActionScript function to be called instead of one of the built-in operations.
And as before, is used to list the columns within the . But here, two non-database columns have been added. An empty column has been inserted at the front of the list. This forces to display the tree in its own column, rather than in the actual data column (and this technique can be used whether or not summary data is being displayed). In addition, a row named “Total” has been added to the end of the column list to display the summary totals. The tags point to the “Total” as the destination for calculated summary data. This is optional, the “Total” column could have been omitted (both from the list and from the tags) in which case the summary values would have been displayed within the field being summarized (in this example the “PRICE” column).
As you can see, adding summary data to an is not at all difficult once grouping has been implemented.
One last note, the example data used here is not ideal, as each customer has a single order, and only one order (for customer “White, Sue”) has more than one item. You may want to add some data to the example tables to better demonstrate how summary data works. Or just use your own data.