Book Review - JSF 1.2 Components

I was offered a chance to review a copy of the JSF 1.2 Components book by Ian Hlavats and published by Packt Publishing. The book covers a number of different JSF frameworks including 1.2 Reference Implementation (RI), Facelets, Apache Tomahawk and Trinidad, ICEfaces, and RichFaces. My overall impression of the book is a 2/5 stars.

Why?

When you are trying to teach someone to use a new technology, the source code must work, and the effort to get it to work should be minimal. This is not the case with the accompanying source code. There are a number of errors in the code that a modern IDE and technical reviewer should catch. This applies to the code examples in the book. The configuration and requirements to use Eclipse for the projects are a shame for anyone wanting to use another IDE. The projects should have been set up to use Apache Maven to make them IDE neutral.

I also do not like partial code examples. I believe that code should stand on its own. If you are going to provide code snippets, then the code provided must be complete and functional. This was not the case.

Chapter Summaries

The first chapter covers the very basics of JSF RI. This is a very shallow introduction to the RI.

Chapter 2 Covers Facelets. It is one of the best explanations I have seen on Facelets and is very easy to understand and follow. This chapter makes the book worth buying if you are interested in Facelets technology.

Chapter 3 on Apache Tomahawk does a good job of representing the framework. There are a lot of great components in Tomahawk (75+) which play nicely with other JSF frameworks.

Chapter 4 covers Apache Trinidad (A.K.A. Oracle ADF Faces). It does a reasonable job of demonstrating the framework, and has inspired me to look a little further into it. I found it very easy to use, and found myself trying other components which were not covered in the book. I do have some issues around the code examples and implementation which I will cover in the detailed section below.

Chapter 5 covers ICEfaces. It is a really good example of some of the things that ICEfaces can do, and the components are very eye catching. My chief complaint with ICEfaces compared with some of the other frameworks is that it is really messy to set up tables, and sorting.

The book fumbles at the finish line. The chapters of the book on Seam (Chapter 6) and Richfaces (Chapter 7) are totally blown. The authors decision to do Seam before RichFaces and not separate the code base was a bad decision. The chapters themselves are not too bad, but the code would not run. Since Chapter 7 depends on Chapter 6 code, the result is a quagmire.

I created a Maven POM for Chapter 6 and set to work on the dependency issues. I had done the same thing for the previous chapters by converting them into Maven projects. This time the project failed to run and there were a number of issues. In fact, too many issues to overcome. I resolved to use the code and instructions provided by the author and the code failed to run as well. I am convinced that the Seam and database portions of the code examples are not configured correctly. After spending a week trying to make it work in both Maven and Eclipse, I quit. It should not require me spending hours trying to make it work. The code is supposed to make it easy for me to get a handle on these technologies and not troubleshoot it.
I can not validate that the code works as the author has written it in the book since the code does not work in the provided examples.

Summary

My overall impression of the book is a 2/5 stars. I really liked some portions of the book, like chapter 2 on facelets, and chapters 3 & 4 on Apache MyFaces component frameworks.

Two chapters (6 & 7) appear to provide some really relevant data, but the sample code provided with the book on which this chapter depends falls short. As a result, I can not really assess Chapter 6. Chapter 7 depends on the successful function of Chapter 6 for the most part, and is really short changed by the failure of the Seam and database connectivity. Some of the sample code for Chapter 6 works so that you can get a glimpse into the power of RichFaces.

I noted that I made a number of the examples into Apache Maven projects. I would offer them out to the public, but the code has no licensing noted in the source, and was really meant for my consumption. If you are the author, publisher, or an interested party, I will provide it to you on request.

I would really like it if Packt would consider requiring all of their sample code be provided in Maven projects. This would make the them IDE neutral, and ensure the quality of the projects by providing exact dependencies.

Chapter Details and Errata

These are notes, errors, comments, and impressions from the chapters. I suggest that if you encounter any errors in the book, please check here to see if I have addressed them.

Chapter 1

(Pages 28-29)
The images on pages 28 and 29 should be swapped. The image on page 29 is for the code snippet on the top of page 28, and vice versa.

(Page 31)
This note should be added to page 31.

Note: Classes which are used as select options <f:selectitem> need to have equals() and hashCode() methods implemented. Otherwise you will get a strange validation error whose description is not indicative of the true root cause of the error.

(Page 32)
The author makes mention of a potential issue with <h:selectManyMenu> having issues on many browsers. I tried it on Firefox 3.5.+ on Mac OS X 10.6 and did not see the issues the author mentions. This may be applicable to earlier versions of Firefox using other operating systems.

Chapter 2

If you are trying the code examples from the book and the html is not formatted correctly, please check the xml namespace in the facelets html tag. It should have the following xmlns in bold added so that it displays html correctly.

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:t="http://myfaces.apache.org/tomahawk">
...
</html>

I would also recommend adding the correct DOCTYPE to the header to make sure that the document is well formed. The Transitional XHTML example is shown below and will work in most applications.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

(Page 51)
The web.xml file has some of the more important information in bold, but really should include descriptions of what these parameters are in the actual web.xml. See the example below which includes descriptions.

web.xml

---

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
    <display-name>chapter2</display-name>

    <!-- Optional JSF-RI Parameters to Help Debug -->
    <context-param>
        <param-name>com.sun.faces.verifyObjects</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <param-name>com.sun.faces.validateXml</param-name>
        <param-value>true</param-value>
    </context-param>
    
    <!-- Use Documents Saved as *.xhtml -->
    <context-param>
        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
        <param-value>.xhtml</param-value>
    </context-param>

    <!-- Special Debug Output for Development -->
    <context-param>
        <description>
            Setting this to true will cause the FaceletViewHandler to print out debug information in an easy to use screen
            when an error occurs during the rendering process.
        </description>
        <param-name>facelets.DEVELOPMENT</param-name>
        <param-value>true</param-value>
    </context-param>
    
    <context-param>
        <description>
            A boolean value that tells the compiler to skip comments (default is true).
            Even if you comment out code in your page, the tags will not be compiled but expressions (EL) will be
            treated as if they were inlined-- still compiled and evaluated for output in the document.
            Skipping comments will remove all comments completely from the document.
        </description>
        <param-name>facelets.SKIP_COMMENTS</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <description>
            When a page is requested, what interval in seconds should the compiler check for changes.
            If you don't want the compiler to check for changes once the page is compiled, then use a value of -1.
            Setting a low refresh period helps during development to be able to edit pages in a running application.
        </description>
        <param-name>facelets.REFRESH_PERIOD</param-name>
        <param-value>1</param-value>
    </context-param>
    <context-param>
        <description>
            A semicolon (;) delimitted list of resources that Facelets should use. If no resource paths are specified,
            Facelets will handle all requests (DEFAULT). If one or more paths are specified,
            Facelets will only use the ones specified, otherwise fall back on the parent or default ViewHandler (JSP).
            Note, this requires the FacesServlet in your web.xml to be mapped with a prefix for capturing multiple file types ex: /faces/*.
        </description>
        <param-name>facelets.VIEW_MAPPINGS</param-name>
        <param-value>*.xhtml</param-value>
    </context-param>
    <context-param>
        <description>
        The buffer size to set on the response when the ResponseWriter is generated.
        By default the value is -1, which will not assign a buffer size on the response.
        This should be increased if you are using development mode in order to guarantee that the response
        isn't partially rendered when an error is generated.
        </description>
        <param-name>facelets.BUFFER_SIZE</param-name>
        <param-value>8192</param-value>
    </context-param>
   
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.jsf</url-pattern>
        <url-pattern>/faces/*</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
    <welcome-file-list>
        <welcome-file>forward.jsp</welcome-file>
    </welcome-file-list>
</web-app> 

---

(Pages 56-57)
Note: The output from the debug does not work on facelets 1.1.14 because of a JavaScript error. You must use facelets version 1.1.11, or 1.1.15B1 for the debug to work properly. (See Facelets issue #292 on facelets.dev.java.net.)

(Page 66)
This code sample would not work for me. I needed to add <h:panelGroup> wrappers around the <ui:include> tags in the <h:panelGrid> components.

An alternative to would be to make the customerList a component and not a composition.

(Pages 77-78)
The templateClient02.jsf and templateClient02a.jsf code has a <ui:debug> components shown in the code. These will not work here. It must be in the template for it to work.

(Page 87)
The fourth paragraph has a typo which should be "Facelets and JSP..."

Chapter 3

(Page 97)
The <t:inputCalendar> component does not have a type attribute.

(Page 104)
There should be an explanation why the encoding type (enctype) is required on the <h:form> component. This is something that has been changed from the other examples and could easily be overlooked.

Note: The file:/// syntax will not work on Firefox, or Safari. It may not work on other browsers as well. This is a built-in security feature of those browsers. So this example will not work using those browsers. If you want to be able to actually click on the hyperlinks and have them work, I had to use Lynx. This is a command line browser which does not incorporate this security mechanism.

(Page 116)
The action on <t:commandNavigation> for products does not match the provided code. It should be <t:commandNavigation value="products" action="#{productBean.displayProducts}"/>

(Page 125)
The <t:jscookMenu> theme should be theme="ThemePanel" to match the provided code.

(Page 136)
Note: The <t:dataTable> component must be inside a <h:form> component for the table sorting to work.

Chapter 4

(Page 142)
Note: The installation and configuration section has an example of how to set up Apache Trinidad using facelets. This is contrary to the preferred method which is detailed on the Apache Trinidad Installation page. Below is a copy of my web.xml file which has the correct Apache Trinidad configuration.

web.xml

---

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

    <!-- BEGIN Apache Trinidad BEGIN -->

    <context-param>
        <description>
            Note: TrinidadFaceletViewHander must be the alternate view handler if SessionChangeManager is used.
        </description>
        <param-name>org.apache.myfaces.trinidad.ALTERNATE_VIEW_HANDLER</param-name>
        <param-value>org.apache.myfaces.trinidadinternal.facelets.TrinidadFaceletViewHandler</param-value>
    </context-param>
    
    <context-param>
        <description>
            Unfortunately, Facelets provides no hook for plugging the PageResolver into the logic
            handling "facelets.VIEW_MAPPINGS". You should leave "facelets.VIEW_MAPPINGS"
            unset and use "org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS" instead.
        </description>
        <param-name>org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS</param-name>
        <param-value>*.xhtml</param-value>
    </context-param>

    <context-param>
        <description>
            Trinidad also supports an optimized strategy for caching some
            view state at an application level, which significantly improves
            scalability.  However, it makes it harder to develop (updates to
            pages will not be noticed until the server is restarted), and in
            some rare cases cannot be used for some pages (see Trinidad
            documentation for more information)
        </description>
        <param-name>org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE</param-name>
        <param-value>false</param-value>
    </context-param>

    <context-param>
        <description>
            If this parameter is enabled, Trinidad will automatically
            check the modification date of your JSPs, and discard saved
            state when they change;  this makes development easier,
            but adds overhead that should be avoided when your application
            is deployed
        </description>
        <param-name>org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION</param-name>
        <param-value>true</param-value>
    </context-param>

    <context-param>
        <description>
            Enables Change Persistence at a session scope.  By default,
            Change Persistence is entirely disabled. The ChangeManager is
            an API, which can persist component modifications (like,
            is a showDetail or tree expanded or collapsed). For providing
            a custom Change Persistence implementation inherit from the
            Trinidad API's ChangeManager class. As the value you have
            to use the fullqualified class name.
        </description>
        <param-name>org.apache.myfaces.trinidad.CHANGE_PERSISTENCE</param-name>
        <param-value>session</param-value>
    </context-param>

    <context-param>
        <param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name>
        <param-value>true</param-value>
    </context-param>

    <!-- Use client-side state saving.  In Trinidad, it is an
       optimized, token-based mechanism that is almost always a
       better choice than the standard JSF server-side state saving. -->
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
        <!--param-value>server</param-value-->
    </context-param>

    <!-- Trinidad by default uses an optimized client-side state saving
       mechanism. To disable that, uncomment the following -->
  <!--context-param>
    <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>
    <param-value>all</param-value>
  </context-param-->

<!-- END Apache Trinidad END -->

    <filter>
        <filter-name>trinidad</filter-name>
        <filter-class>org.apache.myfaces.trinidad.webapp.TrinidadFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>trinidad</filter-name>
        <servlet-name>Faces Servlet</servlet-name>
    </filter-mapping>

    <!-- Faces Servlet -->
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    </servlet>

    <!-- resource loader servlet -->
    <servlet>
        <servlet-name>resources</servlet-name>
        <servlet-class>org.apache.myfaces.trinidad.webapp.ResourceServlet</servlet-class>
    </servlet>

    <!-- Faces Servlet Mappings -->
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>/faces/*</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>resources</servlet-name>
        <url-pattern>/adf/*</url-pattern>
    </servlet-mapping>

    <!-- Welcome Files -->
    <welcome-file-list>
        <welcome-file>/forward.jsp</welcome-file>
    </welcome-file-list>

</web-app>

---

(Page 144)
Note: I also found that a number of examples use <h:form> instead of <tr:form> which is also preferred.

(Page 145)
The component <tr:chooseColor> has a closing tag before the id attribute, and will not work unless it is removed.

(Page 147)
The references to commandButton and outputText should use the tr prefix instead of the h prefix since it is supposed to be demonstrating the Apache Trinidad components and not the RI.

(Page 150)
The <tr:inputListOfValues> has columns="25" in the code.

The <tr:panelGroupLayout> rendered attribute has a coding error in it. It should have a space between ne and null like this rendered="#{productBean.selectedProduct ne null}".

Also this example is incomplete since it does not show, or discuss the pop-up dialog which is part of the component functionality.

(Page 153)
The last paragraph which discusses validating using client side alerting should be a note to stress its importance.

(Page 158)
The facets which are listed under the <tr:statusIndicator> tag have incorrect attributes. They should be name and not message.

(Page 159)
The <tr:poll> component should use the slowPollListener under the pollListener attribute.

(Page 160)
The backingBean component in the first example does not contain slowNumber field.
The second example on the page uses backingBean.pollListener which should actually be backingBean.progressListener.

(Page 165)
The provided code does not contain a styleClass attribute in the <tr:panelGroupLayout> component. Also the <tr:spacer> component has a height of 10 in the provided code.

(Page 166)
The image does match the actual output unless you remove the styleClass attribute from the code.

(Page 167 and 168)
The <tr:commandButton> actionListener does not exist. It should be actionListener="#{productBean.saveSelected}".

(Page 171)
The inlineStyle of the <tr:column> component should have a semi-colon at the end of the value.

(Page 173)
This section was a total failure. The provided code does not work.

(Pages 175 and 177)
This section did not work, nor did the sample code for using XMLMenuModel items.

(Page 191)
The image does not match the code example. The image is for another component dialog.
In addition, the color chooser dialog does not convert the color back correctly. I had to modify the Customer.getFavoriteColorHexValue() to get it to work.

public String getFavoriteColorHexValue() {
String value = null;
if (favoriteColor != null) {
int rgb = favoriteColor.getRGB();
value = Integer.toHexString((rgb & 0xffffff) | 0x1000000).substring(1);
}
return "#" + value;
}

Chapter 5

(Page 196)
The <ice:inputText> for name has an error in the backingBean syntax. It should be value="#{backingBean.name}".

(Page 200)
The components require <f:dateTimeConverter>s to display the values correctly.

(Page 205)
The Toco-Toucan.jpg image name is missing the "-" so the image would not display.

(Pages 212 and 213)
This example is poorly designed and impractical. It displays column numbers at the tops of each column. Who would do that? This should be more practical and show column names for the values in the columns.

(Page 214)
The <ice:commandSortHeader> for birth date should be removed since the code is duplicated.

(Page 215)
The data model UML is not correct. It should be SortableDatamodel <T extends Selectable>.

(Page 216)
The afterPhase method has an argument arg0. This should be phaseEvent which is more descriptive in keeping with a more modern coding style. The code will work, but it is considered bad form.

(Pages 218 and 219)
The <ice:commandSortHeader> for birth date should be removed since the code is duplicated.

(Page 225)
I must admit adding data set paging using ICEfaces is very easy.

(Pages 238-239)
The code here is irrelevant here and should be removed. It is duplicated in the next section on page 239 which actually covers this component.

Chapter 6

(Page 256)
The second paragraph has a typo. It should be "...specified in advance,...".

(Page 275)
The name of the bean should be ShippingCalculatorBean. The t in calculator is missing.