The class UICellSetTable will implement the
renderer independent part of the cellSetTableFacelet
tag. Extends from UIComponentBase and implements NamingContainer.

It must have three children components, one
for each cellSetTable area (column axis, row axis and data cells). This class specializes
the processDecodes(), processValidators() and processUpdates() methods to call setCurrentArea to establish de proper area before calling the corresponding method
on each children.

This class also specializes getClientId to create
area independent identifiers for child controls. It specializes queueEvent to wrap
any bubbled up event with a wrapper event identifying the area where the event
was produced. Specializes broadcastEvent to unwrap any wrapped event and set the current area before
dispatching it.

The classes UICellSetAxis and UICellSetCells will
implement the renderer independent part of the children of UICellSetTable: the
former will implement the components for both query axis (rows and columns) and
the later will implement the table of data cells.

Both classes have a setCellIndex method
that parallel the setRowIndex method of the standard component UIData; saves the state of the
current cell and sets the cell (i,j) as the current cell. The meaning of cell
depends on the component class:

·For UICellSetCells it’s the CellSet data cell cs.getCell(Arrays.asList(j,i)), where cs is the CellSet bound to the component.

·For UICellSetAxis it’s the i-esim member at position j csa.getPositions().get(i).getMembers().get(j) where csa is the CellSetAxis instance bound to the component.

As the UIData component these classes specialize
the processDecodes, processValidators and processUpdates to iterate over every cell in its bound data set and call setCellIndex before
call the corresponding method on its children.

So, our Facelet sample in the previous post
must be slightly modified to fit into this design

This tag renders an org.olap4j.CellSet instance. It mimics someway the behavior of <h:dataTable>: provides the main structure for displaying the CellSet and allows
the page designer to specify the contents for each part of the table.

The tag’s structure is as follows:

<olap:cellSet value=”…” var=”cell”>

<olap:columnAxis>

<f:facet
name=”header”>

<!—

This content
is rendered in the headers

of the column axis dimensions

-->

</f:facet>

<!—

This content is rendered in the members

of the column axis dimensions

-->

</olap:columnAxis>

<olap:rowAxis>

<f:facet
name=”header”>

<!—

This content
is rendered in the headers

of the row axis dimensions

-->

</f:facet>

<!—

This content is rendered in the members

of the row axis dimensions

-->

</olap:columnAxis>

<olap:dataCell>

<!—

This content is rendered in the cells

of the CellSet

-->

</olap:dataCell>

</olap:cellSet>

This markup would produce the following
HTML table, where the background color of the cell identifies the markup piece
used to generate its content

Region

USA

Canada

Measures

Gender

Promotions

Unit Sales

Store Cost

Unit Sales

StoreCost

Male

TV Spot

0

0

0

0

Newspaper Ad

0

0

0

0

Female

TV Spot

0

0

0

0

Newspaper Ad

0

0

0

0

The var attribute in the cellSetTable tag
allows the page to use its value as a variable in EL expressions used within
the children of the cellSetTable. This variable will refer to an instance of the CellSetItemInfo interface
defined as follows:

interface CellSetItemInfo {

public
Hierarchy getHierarchy();

public
Member getMember();

public
List<Member> getPosition();

public Cell getData()

public Axis getAxis();

}

The following table shows, for each
property of this instance, he areas of the table where such a property is
non-null

axis

hierarchy

position

member

cell

The code below shows a simple example for a
<olap:cellSetTable>

<olap:cellSetTable value=”#{olapSample.cellSet}”
var=”cell”>

<olap:columnAxis>

<f:facet name=”header>

<h:outputText value=”#{cell.hierarchy.caption}”/>

</f:facet>

<h:outputText value=”#{cell.member.caption}”/>

</olap:columnAxis>

<olap:rowAxis>

<f:facet name=”header>

<h:outputText value=”#{cell.hierarchy.caption}”/>

</f:facet>

<h:outputText value=”#{cell.member.caption}”/>

</olap:rowAxis>

<olap:dataCell>

<h:outputText value=”#{cell.data.formattedValue}”/>

</olap:dataCell>

</olap:cellSetTable>

The managed bean providing the CellSet would
have the following structure.

I use a RequestScoped in combination with @PostConstruct
and @PreDestroy
methods to open a connection to the olap4j server before any use of the bean,
and close that connection once the request process lifecycle has ended.

In a real-world example the connection can
be retrieved lazily, and we can store the resulting CellSet in a field to avoid
executing the same query several times within the same request.

Background

I initially got in touch with Open Source BI while managing a Pentaho deployment (previously I was involved in another project using SAP BI). So when I faced the development of a small utility requiring BI functionallity, I choose to use some of the foundations of this BI suite. Specifically Mondrian as the OLAP engine and JPivot for data visualization.

While Mondrian seemed very easy to integrate, JPivot was quite more cumbersome and unwieldy so I started looking for alternatives. I was experimenting with version 2.0 of JSF, at that moment, so I tried to find a JSF components library to provide JPivot like functionality.

I could not find it, and the utility development was finally cancelled.

Anyway, personally, the idea of such a component library seemed appealing, and was a nice path to learn about JSF custom components development. For me, the finall push was the release of version 1.0 of olap4j.

The vision of a suite of BI presentation-tier components, pluggable to several OLAP providers using an standarized interface (olap4j), and tha could be integrated into an also standard Web framework (JSF 2.0), by just dropping a .jar file into the project's classpath attracted me more and more.