Red Hat

In Relation To JSF

In Relation To JSF

JSF 2.0. Test Drive PDL. Part 1

Posted by    |       |    Tagged as JSF Rich Faces

When this blog is writing, JSF 2.0 specification reached the Public Review status. Everybody can visit the JSR-314 EG page and download his own copy of it. Comparing to JSF 1.2 when the implementation appeared about one year after the specification is done, Sun is developing the reference implementation, also known as Project Mojarra, at the time with writing the specification. Thus, you can try new features of JSF 2.0 right away downloading the Mojarra 2.0.0 PR release from the project home page: .

JSF 2.0 has some cool innovation features. One of them is PDL (Page Declaration Language). PDL inherits its core functionality from two well known JSF project - Facelets and JSFTemplates. Among all other features, it allows to create new JSF components in declarative manner, without creating a bunch of java classes like it was in the previous JSF versions. In this blog we will test-drive this feature and show the top features of PDL.

Binary Mojarra distribution already contains ezcomp00 and ezcomp01 applications that show the basic of the PDL. We are not going to repeat them, but will create something different. RichFaces has a rich:panel, pretty simple, but useful JSF component. It represents the rectangle with a body and an optional header defined by a facet. The look-n-feel of the rich:panel is defined with some set of css rules. Some of those rules refer to the parameters taken from the skin parameters. I.e. css has static and dynamically generated rules. If header presents, it is filled with background gradient generated by java class that also uses the skin parameters as base colors for generated gradient. The working example of the rich-panel you can see at the main richfaces demo at:

Actually, RichFaces has a CDK (Component Development Kit) that is used for creating all 100+ RichFaces component. CDK is a maven based tool that generates components based on the meta-data, java classes and jspx templates that define a component layout. The rich:panel was exactly the component that we use to test-drive the first versions of CDK. Hence, now we just need to follow the same path, but using a new standard of JSF 2.0 - Page Declaration Language.

Note: JSF 2.0 PDL and CDK JSPX are not very well comparable things. CDK JSPX templates makes sense only for design time. They are compiled into the java classes and the result library does not contain the templates and some sort of interpretation processor. At least, the result code works faster.

The structure of the rich:panel is pretty simple. It has an outer div, body div and header div optionally.

<div class="rich-panel">
    <div class="rich-panel-header">This is a panel header</div>
    <div class="rich-panel-body">The is the panel body</div>

Let's see what we can do using JSF 2.0 PDL. How to create a simple component like the one shown in the ezcompXX demo and described several times in the blogs and introduction articles. I like the JSF 2.0 PREVIEW by Cagatay Civici presentation. It is short and overview the key feature is JSF 2.0. The page where component is used looks like:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
<html xmlns=""
<f:view contentType="text/html"/>

    <title>Panel Test</title>

   <f:facet name="header">
    <h:outputText value="This is a panel header"/>
   <h:outputText value="The is the panel body"/>



We use rich: namespace which is defined at the top of the page as xmlns:rich=" In our case, means we have a folder with the name rich that is located in the {webtoot}/resources/ folder. {webtoot}/resources/rich/ folder contains the panel.xhtml file where the our panel component is located. This is a content of the panel.xhtml file:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns=""
    <composite:attribute name="style" required="false"/>
    <composite:attribute name="styleClass" required="false"/>
    <composite:attribute name="headerClass" required="false"/>
    <composite:attribute name="bodyClass" required="false"/>
    <h:outputStylesheet name="rich/css/panel.css" />
 <div class="rich-panel #{compositeComponent.attrs.styleClass}"
  <div class="rich-panel-header #{compositeComponent.attrs.headerClass}">
   <composite:insertFacet name="header"/>
  <div class="rich-panel-body #{compositeComponent.attrs.bodyClass}" > 
   <composite:insertChildren />

Our component is represented with two tags: composite:interface and composite:implementation. The interface has a declaration for attribute set. For the sake of simplicity, we avoid all other attributes, but add only the ones that represent the component styling. The implementation tag contains the layout of the component. The context of the header is inserted with:

<composite:insertFacet name="header"/>

The panel can contains the number of other component insert. We just use the composite:insertChildren to point to the place where the children will be inserted to. Mojarra 2.0 binary distribution has a pdldocs archive. It contains the documentation to all PDL related tags.

The class attributes of the div tags reference the static name of the default component classes and to the user defined classes wired using EL expressions. The classic h: library has some new components including h:outputStylesheet. We use it to reference the static CSS file with default panel CSS rules. Note, that the used path is relative. However, the root of this relative path is located not where panel.xhtml is located, but where the {webtoot}/resources/ folder is. Thus, {webtoot}/resources/rich/css/panel.css contains:

  border-width: 1px;
 border-style: solid;
 padding : 1px;
 padding : 2px;
    border-width: 1px;
    border-style: solid;
 padding : 10px;

At this moment we are done with basic of the panel. Let's see how to reach the rest of the rich:panel features. To be continued....

JSF2 almost complete!

Posted by    |       |    Tagged as JSF Seam

As you may know, I've been working very closely with the other stake holders in JSF (e.g. Sun, Oracle, Apache) on JSF 2. I just wanted to pull together a few recents threads to give you an update.

First, Ed Burns (the specification lead) posted on the status - not long to go now before the proposed final draft.

Second, Stan Silvert just blogged about using JSF2 in JBoss AS 5. You can read more at


Dropdowns in JSF: Validating the selected value

Posted by    |       |    Tagged as JSF Seam
I'm using <s:convertEntity /> and when I submit the form I get an error message on the page /Value is not a valid option/ — what am I doing wrong?

This commonly asked question on the Seam forum refuses to go away — so lets run through the problem, look at the workarounds and what changes would be needed to JSF to make it go away.

The Background

JSF allows you to specify a converter for any editable value; the converter converts /from/ an Object /to/ a String when rendering the page, and /from/ a String /to/ an Object when submitting a form. JSF comes with some built in converters (e.g. for Date, enums...) or allows you to create a custom converter.

Inside your custom converter you implement getAsString, returning a String, which, when passed to getAsObject on submitting the form, you use to get hold of the Object and return it.

Seam provides <s:convertEntity />, a generic converter which does the job of converting any JPA entity (mapped with annotations or XML, with a simple or composite key). It takes the primary key of the entity, stores it, returns a reference to the location in the key store; when the page is submitted, the key is fetched from the store and used to load the entity.

The Problem

The JSF 1.2 Specification (sections and specify that

...must provide a specialized validate() method which ensures that any decoded value is a valid option (from the nested UISelectItem and UISelectItems children).

In other words, the submitted item must be in the list displayed on the page. As the entity converter loads the selected object from the persistence context when the page is submitted, /the submitted object is not in the displayed list/.

The Workarounds

  1. Display the list and submit the form inside the same long running conversation (so that the persistence context returns the same object both times). This makes caching the list of selectable items hard.
  2. Overriding equals() on the entity (which isn't a a great idea).

The Solution

For JSF 2 this validation should be optional/overrideable (as it is everywhere else in JSF). In this case the converter is doing all necessary validation.

back to top