Dynamic Menus in RichFaces

RichFaces has no built-in functionality for creating dynamic menus, the reason for this could be that a lot of different use case scenarios require different type of dynamic menus. This example presents the most simple case: The menu items are dynamically populated from a list, and an action method is called with the id of the menu item, when the user selects the menu item.

The data of a menu item is represented by the MenuItem class:

public class MenuItem {

 /**
  * Id of the menu item
  */
 private int id;

 /**
  * Label for menu item
  */
 private String label;

 /**
  * Constructor
  * 
  * @param label The label fo the menu item
  * @param id the id of the menu item
  */
 public MenuItem(String label, int id) {
  super();
  this.label = label;
  this.id = id;
 }

 /**
  * @return the id
  */
 public int getId() {
  return this.id;
 }

 /**
  * @return the label
  */
 public String getLabel() {
  return this.label;
 }

 /**
  * @param id
  *            the id to set
  */
 public void setId(int id) {
  this.id = id;
 }

 /**
  * @param label
  *            the label to set
  */
 public void setLabel(String label) {
  this.label = label;
 }

 /**
  * @see java.lang.Object#toString()
  */
 @Override
 public String toString() {
  StringBuilder builder = new StringBuilder();
  builder.append("MenuItem [id=");
  builder.append(this.id);
  builder.append(", label=");
  builder.append(this.label);
  builder.append("]");
  return builder.toString();
 }

}

The dynamic menu is supported by the DynamicMenu class. It provides the list of menu items and an action method:

import java.util.ArrayList;
import java.util.List;

import org.apache.log4j.Logger;
import org.jboss.seam.annotations.Name;

@Name("dynMenu")
public class DynamicMenu {
 
 private Logger log = Logger.getLogger(DynamicMenu.class.getName());

 /**
  * Example action method
  * 
  * @param id the menu item id
  */
 public void action(int id) {
  log.info("Action called with menu item id: " + id);
 }

 /**
  * Returns the list of menu items.
  * 
  * @return the list of menu items
  */
 public List getMenuItems() {

  List menuItems = new ArrayList();

  menuItems.add(new MenuItem("Menu Item #1", 1));
  menuItems.add(new MenuItem("Menu Item #2", 2));
  menuItems.add(new MenuItem("Menu Item #3", 3));

  return menuItems;
 }
}

The following code snippet contains the dynamic menu xhtml example. The key in the dynamic menu items is the <c:forEach> iterator. The namespace declaration is very important, it should be xmlns:c="http://java.sun.com/jstl/core". If you use xmlns:c="http://java.sun.com/jsp/jstl/core" namespace, the iterator won't work!

<h:form xmlns:h="http://java.sun.com/jsf/html">

...

   <rich:dropDownMenu
    value="Dynamic Menu Item Example"
    style="text-decoration: none;"
   >


    <c:forEach xmlns:c="http://java.sun.com/jstl/core"
     var="item"
     items="#{dynMenu.getMenuItems()}"
    >

     <rich:menuItem
      id="menuItem#{item.id}"
      submitMode="ajax"
      value="#{item.label}"
      action="#{dynMenu.action(item.id)}"
     >

     </rich:menuItem>
    </c:forEach>



   </rich:dropDownMenu>

...

</h:form>

Speeding up a Seam Page in an Expensive Way

The Task

Given a Seam 2.2 application with an overview page displaying progress of students aiming to obtain a given certificate (I have changed the original purpose of the application in this article for discretion). The problem: the page was excessively slow. I was asked to cut the display time from 30 seconds to below 5 seconds.
The page looked like in the following: On the left side there are the "Trainees", on the header there are the "Exams", the other table cells contains the latest dates when a student has taken the given exam and the color shows the status. (The given certificate are previously selected, in this case the "Java Programmer" Certificate).

	Declarations, Initialization and Scoping	Flow Control	API Contents	Concurrency	OO Concepts	Collections / Generics	Fundamentals
Alger, Brian	1/3/2011	2/5/2011	3/7/2011	n/a	5/7/2011	6/11/2011	7/19/2011
Algieri, Christopher	1/3/2011	2/5/2011	3/7/2011	4/14/2011	5/7/2011	n/a	7/19/2011
Barnett, Jason	1/3/2011	2/5/2011	3/7/2011	4/14/2011	5/7/2011	6/11/2011	7/19/2011
Dobrin, Adam	1/3/2011	2/5/2011	3/7/2011	4/14/2011	5/7/2011	6/11/2011	7/19/2011
...	...	...	...	...	...	...	...
Fogelson, Benjamin	1/3/2011	2/5/2011	3/7/2011	n/a	5/7/2011	6/11/2011	7/19/2011

Legend:

Finished

Failed

Waiting

Is There a Cheap Solution?

I wanted to solve the problem by applying some kind of "silver bullet", so I entered "speed up seam application" into google. The most interesting article: Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude promised a 100 times ("two orders of magnitude") speed increment by applying the following steps:

• Remove the unnecessary page action calls
• Simplify the EL expressions in conditional rendering
• Avoid calling intercepted methods
• Avoid using the EL variable resolver, use the corresponding context directly to get the variable's value
• Reduce the size of the resulting HTML code by reducing the length of IDs, paths; link JavaScript and CSS instead of embedding
• Disable facelet refresh

Most of the tips are about changing the JSF page or the "page.xml", I have tried my best but with no luck...

Caching

I have tried to use EHCache using this (and some other) guides: Seam and EhCache – A Short Primer. After installing EHCache I have to admit the performance was still low, although after refreshing the page, it was displayed a bit faster.

Investigation

At this point it was clear that no cheap tricks will work, so I had to find out what takes 30 seconds to display the page. Adding ad-hoc instrumentation code into the page action method and into the page xhtml code and by measuring the time using Google Chrome Developer Tools, I found out that

• 33% of the time spent on database queries and preparing the data in the action method
• 33% of the time spent on processing the xhtml page and produce the output
• 33% was spent on displaying the page by the client (waiting for the page data)

First Bottleneck: Data model


By looking at the Hibernate entities and queries, it was astonishing to see how complicated is to collect the data to display the overview. Let us see the data model which is important for the display.

Fig 1. The actual data model

To get a given Certificate the Trainees should take Exams (Certificates and Exams are linked together, but not shown in this model). If a change happens in the Trainee's status (e.g.: finishes an exam), a new Training Event is created linked to a Status. To display the table of all Trainees who are eager to get a given Certificate, the latest Training Events for a given Trainee-Certificate-Exam triplet should be queried. To select the latest training events a sub query is used:

SELECT 
  te FROM TrainingEvent te 
WHERE 
  te.certificate = :certificate AND 
  te.timestamp 
IN 
(SELECT 
    MAX(teLatest.timestamp) 
    FROM 
      TrainingEvent teLatest
    WHERE 
      teLatest.certificate = :certificate 
   GROUP BY 
      teLatest.exam)

Second bottleneck: RichFaces


The number of Exams for a given Certificate is variable and assigned in different parts of the application. To enable displaying dynamic columns for a table, RichFaces has the rich:columns JSF component. In our application this looked like this:

<rich:columns index="ind" style="background-color: #{certificateBean.getLatestTraining(trainee, exam) != null ?certificateBean.getLatestTraining(trainee, exam).status.backgroundColor :'#e0e0ff'};" styleclass="tightTable" value="#{certificateBean.getExams}" var="exam">
    <f:facet name="header">
        <h:outputtext value="#{exam.name}">
    </h:outputtext></f:facet>
    <ui:include src=" /trainingEventPanel.xhtml">
        <ui:param name="event" value="#{certificateBean.getLatestTraining(trainee, exam)}">
    </ui:param></ui:include>
</rich:columns>

The problem with this is the extensive number of calls to

certificateBean.getLatestTraining(trainee, exam)
 

I have eliminated the "heavy" calls to this method to check if rich:columns can be used effectively, but my "experiments" showed using rich:columns inevitably goes hand in hand with a lot of EL expression evaluation accountable for poor performance.

Terminal Solution


I have decided to basically rewrite the whole code, but leave the Hibernate entities alone — changing them would have meant changing the whole application. On the database/entities level I left unchanged everything, but my new logic was to implement a specific cache for the data needed to display the page and on the page I discarded the RichFaces components (rich:dataTable, rich:columns), instead I tried to emulate them with plain and simple HTML <table> tag.

Seam components, displayed in the following figure, are used for caching. The "AppCache" is an Application scope component, which is initialized at the start of the application. It holds the TraineeEventData component which contains the data to be displayed (by Certificate). The TraineeEventDataGenerator component is used to initially "generate" the data or refresh after a change. The TraineeEventDataLoader component is used to query the data from the database, for greater efficiency it uses scalar queries (instead of entity queries) to generate much less network traffic.

Fig. 2: The Caching Components

On the display side, instead of rich:dataTable, simple HTML table is used for display. The rows and columns are displayed by using <ui:repeat> components. The TraineeEventData has a method which can provide the information for the table cells as a linear list, so the HTML generation can be very quick.

<table id="traineeEventTable" class="te_table">
    <!-- header rows -->
    <tr class="te_header_row">
        <ui:repeat value="#{traineeEventTable.getHeaderCells()}" var="cell">
            <td class="#{cell.getStyleClass()}" width="#{cell.getWidthRef()}">
                <s:fragment rendered="#{cell.renderColumnHeader()}">#{cell.getContent()}</s:fragment>
            </td>
        </ui:repeat>
    </tr>
    <!-- normal rows -->
    <ui:repeat value="#{traineeEventTable.getRows()}" var="row" offset="1">
        <tr class="te_normal_row">
            <ui:repeat var="cell" value="#{row.cells}">
                <td width="#{cell.columnIndex==0?'200':''}" bgcolor="#{cell.getBackgroundColorRef()}" class="#{cell.getStyleClass()}">
                    <!-- Trainee names -->
                    <s:fragment rendered="#{cell.renderTraineeHeader()">
                        <table class="te_trainee_table">
                            <tr>
                                <td>
                                    <h:outputText rendered="#{cell.renderTraineeHeader()}" value="#{cell.trainee.traineeDisplayName}" id="traineecell" title="#{cell.hint}"/>
                                </td>
                            </tr>
                        </table>
                    </s:fragment>
                    <!-- not available content -->
                    <s:fragment rendered="#{cell.isNotAvailable()}">n/a</s:fragment>
                    <!-- normal content -->
                    <s:fragment rendered="#{cell.isContentRendered()}">
                        <h:outputText style="color: #{cell.textColorRef};" id="cellcontent" value="#{cell.content}" title="#{cell.hint}"/>
                    </s:fragment>
                </td>
            </ui:repeat>
        </tr>
    </ui:repeat>
</table>

The s:fragment component is used to control generation of entire blocks.

What happens on an update which affects the trainee status table? Originally there was a periodic process using Quartz scheduler to update the table, but it was inadequate for the users. Then I was thinking about making a Hibernate event handler which observes changes in the appropriate entities and updates the data when necessary. The final solution is even simpler, a small utility method is called on those locations when the data is changed:

package com.trainee.util;

import com.trainee.TraineeEventDataGenerator;

import org.jboss.seam.Component;

public class AppCacheUtil {
 /**
  * Calls the Application Cache Updater to update the trainee status table
  * data
  */
 public static void updateAppCache() {

  TraineeEventDataGenerator generator = (TraineeEventDataGenerator) Component
    .getInstance("traineeEventDataGenerator");
  generator.generate();

 }
}

Moral

What lesson we can draw from this case? The first is that the ER model should be always efficient even if the application we are working on is just a prototype (as it were in my case). With a better data model the page display time could have been initially much less. On the other hand the current technology (e.g.: RichFaces) using out-of-the-box is not always able to provide the desired performance and in these cases a custom solution should be made.