In a recent article (https://technology.amis.nl/2013/04/02/adf-dvt-using-the-tree-map-visualization-component-to-compare-relative-sizes-and-distributions/) I discussed the ADF DVT Treemap component. This component visualizes data in such a way that comparisons between data values for different records and categories can quickly be made. The size of areas is a measure for some numerical value. As an additional dimension, the color of the areas can be used to identify groups (all members of the group having the same color) or to visualize a second numerical value (color can range for example from dark red to rich green depending on the net revenue per record).
This article describes the situation where we want to use multiple Treemap instances lined up. Each Treemap instance represents a collection of records on one or possibly multiple levels. Each instance can be drilled down into independently. And each instance can represent a different data set, even though we want to compare these data sets. Using a PanelGridLayout, it is easy to position multiple instances in a row or a grid. Using the inline style to scale the width and height of the Treemap instances, we can set the relative size of the treemaps.
The example presented here is based on two ADF BC ViewObjects – one returning Departments with some department level aggregations and the other returning Employees with their name, job and salary. There is a ViewLink between the two ViewObjects, that makes it easy to access the Employees in a certain Department.
The resulting data visualization is shown here:
The sizes of the areas depicting individual employees can be compared across the four Treemap instances: King earns most, Scotty, Jones and Blake come next. The sizes of the Treemap instances themselves are scaled according to the salary sum in these departments. Accounting ranks first, Research is the runner up with Operations and Sales closing the rankings. A quick SQL query confirms that this is the correct visualization and interpretation:
Implementing the multi-treemap
The implementation of this ‘set of treemaps’ is fairly straightforward – with some small tricks applied.
The Model is the same as used in the earlier article https://technology.amis.nl/2013/04/02/adf-dvt-using-the-tree-map-visualization-component-to-compare-relative-sizes-and-distributions/. The ViewController project contains a page with Treemap based on the (detail) collection DepartmentDetails1.
The tree binding:
The page also has a binding for an iterator based on the DepartmentMasters1 collection:
The page contains the treemap inside a panelGridCell that is inside a af:iterator that iterates over the rows in the DepartmentMasters1Iterator. For each department, a treemap is rendered:
The interesting elements in this page are of course the inlineStyle defined on the treemap that specifies the relative height and width. These are both calculated using the scaleFactorCurrentDepartment property on the iteratorBean. This is a request scope bean that is also invoked from the outputText that is rendered underneath the treemap. This outputText indirectly plays to parts: it displays the name of the department – the value returned from the method getGoNext() on the iteratorBean. And by invoking that method – that moves the master iterator to the next record – the outputText as a result ensures that the next batch of details is returned to the treemap’s DepartmentDetails.treeModel. Note: I am sure there other, perhaps better ways of feeding multiple sets of detail records to the treemap, but this one at least does the job with fairly minimal coding effort.
The IteratorBean is not my finest work either, but again: it does the job I need it for. It calculates the scalingFactor, either for the squarified case (see discussion below) or the slicedAndDiced case, and it moves the master iterator to the next record meanwhile returning the Department’s name.
Note: when the layout of the treemap instances is not slicedAndDiced but squarified, then the scale factor needs to be calculated differently. Right now, both width and height are scaled which means that for squarified areas, the size is reduced by the square of the scalefactor. The result would lead to wrong interpretations as the next figure demonstrates. Without using the correct scalefactor (the square root of the one used for one dimensional layouts) the user may be led to believe that Blake earns less than Clark, which is not the case in reality (3420 vs. 2940).
Using the squareroot of the previously used scalefactor, the squarified visualization becomes:
The underlying data:
Resources
Download the JDeveloper 11gR1 PS6 (11.1.1.7) application: TreeMapDemo.
Discussion thread on the OTN Forums about how to get access to multiple sets of detail records in a single page request – https://forums.oracle.com/forums/thread.jspa?messageID=10732526
