Red Hat

In Relation To Sergey Smirnov

In Relation To Sergey Smirnov

JSF 2.0. Test Drive PDL. Part 4a. Happy End

Posted by Sergey Smirnov    |       |    Tagged as JSF Rich Faces

In the previous article we spoke about annoying issue of the Mojarra 2.0.0 PR when the empty attributes are rendered to the final html code. The issue was posted to the Mojarra project: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=940

Now, it is fixed. Let's take a new version of Mojarra 2.0.0 . It is not a PR release, but the SNAPSHOT dated 01/27/08.

The SNAPSHOT has two more surprises.

First, we can use c:if to have a conditional insert now. We speak about it in the Part 2.

Second, there is no composite:insertChildren any more. This tag was replaced with composite:renderUsingPageChildren. It is more correct semantically, but requires some time to memorize.

Ok, this is code of the component that works:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:c="http://java.sun.com/jsp/jstl/core"
      xmlns:composite="http://java.sun.com/jsf/composite">
 <head>
  <title>panel</title>
 </head>
<body>
 
<composite:interface>
    <composite:attribute name="style" required="false"/>
    <composite:attribute name="styleClass" required="false"/>
    <composite:attribute name="headerClass" required="false"/>
    <composite:attribute name="bodyClass" required="true"/>
</composite:interface>
 
<composite:implementation>
    <h:outputStylesheet name="rich/css/panel.css" />
 
 <div class="rich-panel #{compositeComponent.attrs.styleClass}"
   style="#{compositeComponent.attrs.style}"
   onclick="#{compositeComponent.attrs.onclick}" 
   ondblclick="#{compositeComponent.attrs.ondblclick}"
   onkeydown="#{compositeComponent.attrs.onkeydown}"
   onkeypress="#{compositeComponent.attrs.onkeypress}"
   onkeyup="#{compositeComponent.attrs.onkeyup}"
   onmousedown="#{compositeComponent.attrs.onmousedown}"
   onmousemove="#{compositeComponent.attrs.onmousemove}"
   onmouseout="#{compositeComponent.attrs.onmouseout}"
   onmouseover="#{compositeComponent.attrs.onmouseover}"
   onmouseup="#{compositeComponent.attrs.onmouseup}">
  <c:if test="#{! empty compositeComponent.facets.header}">
   <div class="rich-panel-header #{compositeComponent.attrs.headerClass}">
    <composite:insertFacet name="header"/>
   </div>
  </c:if>
 
  <div class="rich-panel-body #{compositeComponent.attrs.bodyClass}" > 
   <composite:renderUsingPageChildren />
  </div> 
 
 </div>
</composite:implementation>
</body>
</html>

This is a deployed example: http://livedemo.exadel.com/richfaces4-panel-4a/home.jsf

If you look at the result html code, you can see what no more empty attributes inserted.

JSF 2.0. Test Drive PDL. Part 4. PassThru attributes

Posted by Sergey Smirnov    |       |    Tagged as JSF Rich Faces

Every JSF component has some specific attribute set unique for it. At the same time, almost all UI components have attributes that are common for all of them. For example, onclick, ondblclick, onblur, onmouseover, onmouseout, onmousedown and so on. They are named PassThru because they are rendered one-to-one to the final html layout.

RichFaces CDK uses a special meta-attribute x:passThruWithExclusions. Like:

<div x:passThruWithExclusions="id,value,styleClass,class" ....>

This attribute directs to insert all PassThru attributes as attributes to this particular div except ones that are explicitly mentioned. Just one attribute, short and not so hard. Let see how JSF 2.0 PDL might help.

In the first article about PDL, we define only four style kind attributes for the sake of simplicity.

<composite:interface>
    <composite:attribute name="style" required="false"/>
    <composite:attribute name="styleClass" required="false"/>
    <composite:attribute name="headerClass" required="false"/>
    <composite:attribute name="bodyClass" required="false"/>
</composite:interface>

Now, we are going to complete the missing part. According to the rich panel TLD documentation, it has 10 PathThru onxxxxxx attributes. To test how they work let's add the following to the test page:

  <rich4:panel onmouseover="this.style.backgroundColor='#F9F9FF'"
      onmouseout="this.style.backgroundColor='#FFF'">
   <f:facet name="header">
    <h:outputText value="This is a header"/>
   </f:facet>
   <h:outputText value="panel with header"/>
  </rich4:panel>

BTW, the composite:interface above contains explicit declaration for four style attributes. What happen if we remove them like that:

<composite:interface>
</composite:interface>

Actually, nothing is changed. The component and its styling work without any changes. This is because of the Facelets feature when Facelets implicitly pass any attributes defined by the end developer, instead of classic JSP where missing an attribute name in the TLD file is a big deal. Let's consider this Facelets feature as an advantage, at least for the size of the component code.

One drop of poison infects the whole tun of wine - if you have a typo in the attribute name, figuring it out is your personal problem. No any warning. However, declaring the attribute explicitly in the composite:interface, even the required="true" does not help. Still the same silence.

Does the composite:interface make sense at all. Yes!!! Do not forget about the most fabulous keyword of the JSF market - the Tools. The JSF tool, if it is smart enough, prompts you with the list of possible attribute sorting them by priority, helps with signature of the method and so one. According to the pdldoc for composite:attribute, it has a lot of useful (for the tools) attributes.

Let's return to the topic. Does the ability to implicitly declare attributes work for our onmouseover, onmouseout? ...Partly. We do not need to declare them implicitly in the composite:interface section (ok, ok. we still need to be kind to the future tools). However, PDL has no idea where to insert them in the composite:interface section. Thus, the test example does not work yet.

Mojarra implementation of PDL has nothing to shortcut the size of required code. Copy/Paste is a way to go. We will add the following as attributes of the top div:

onclick="r#{compositeComponent.attrs.onclick}"
ondblclick="r#{compositeComponent.attrs.ondblclick}"
onkeydown="r#{compositeComponent.attrs.onkeydown}"
onkeypress="r#{compositeComponent.attrs.onkeypress}"
onkeyup="r#{compositeComponent.attrs.onkeyup}"
onmousedown="r#{compositeComponent.attrs.onmousedown}"
onmousemove="r#{compositeComponent.attrs.onmousemove}"
onmouseout="r#{compositeComponent.attrs.onmouseout}"
onmouseover="r#{compositeComponent.attrs.onmouseover}"
onmouseup="r#{compositeComponent.attrs.onmouseup}"

Now, we can see how it works: http://livedemo.exadel.com/richfaces4-panel-4/home.jsf

Looks like we are all set. However, let's look what is actually rendered:

 <div class="rich-panel " style="" onclick="" ondblclick="" onkeydown="" 
        onkeypress="" onkeyup="" onmousedown="" onmousemove="" 
        onmouseout="this.style.backgroundColor='#FFF'" 
        onmouseover="this.style.backgroundColor='#F9F9FF'" onmouseup="">
   <div class="rich-panel-header ">This is a header
   </div>
 
  <div class="rich-panel-body ">panel with header
  </div> 

 </div>

We have a bunch of empty attributes out. Even the browser can have a deal with that, it is not acceptable result the end application developers will be happy with. The attribute should not appear in the result code if it is empty. So far, I did not find a solution how to avoid it in Mojarra 2.0.0 PR. The issue is posted.

JSF 2.0. Test Drive PDL. Part 3. Resources

Posted by Sergey Smirnov    |       |    Tagged as JSF Rich Faces

If you compare the look-n-feel of our new panel after step #2 and the one on the richfaces-demo, you can see one important difference. Our new panel misses the gradient in the header background.

Let's try to find a solution using JSF 2.0 PDL.

RichFaces components have one important peculiarity. They are skinnable based on the predefined set of skin paramaters. Most graphic images used in the components, such as the gradient background image of the rich panel, are not static, but generated with the java classes using the same set of skin-parameters.

In the JSF 2.0 PDL, we can refer to a resource such as an image using the following expression:

#{resources['foo/bar/foobar.gif']}

According to the Mojarra spurce code, it reads only the static resource from the classpath and hardcodded folder 'resources' from the web root. Mojarra does not presume that resource can be generated dynamically. Thus, for the sake of simplicity, let's drop the idea of skinnability for now and take the gradient for default blueSky skin.

We have drop the static image to the {webroot}/resources/img/ folder and add just three lines to the css file:

.rich-panel-header{
 ....... 
 background-position:left top;
 background-repeat:repeat-x;
 background-image: url(#{resource['rich/img/panel_header.png']})
}

That is it. We can see the gradient in the panel header background now. The new panel after step #3 looks like that:

http://livedemo.exadel.com/richfaces4-panel-3/

JSF 2.0. Test Drive PDL. Part 2. Conditional Insert

Posted by Sergey Smirnov    |       |    Tagged as JSF Rich Faces

As it was mentioned previously, rich:panel shows the header only if the facet name="header" is defined. Otherwise, it is just omitted.

In case the header presents, its content is wrapped with div:

  <div class="rich-panel-header #{compositeComponent.attrs.headerClass}">
   <composite:insertFacet name="header"/>
  </div>

What happens in the code above if panel has no header facet on the xhtml page? PDL processor just inserts nothing inside the div without any notes (the same happens, BWT if you have a typo in the facet name). However, it is not what we need, as we need to omit the whole div.

In general, it looks like a common use case: if facet is missing, the whole block that represents the facet in the final layout is omitted. I did not find anything like that in the pdldocs. The second idea was to use a conditional operation.

The following EL returns true if header facet presents. Otherwise, it returns false.

#{! empty compositeComponent.facets.header}

Thus, the following snippet is a solution:

<c:if test="#{! empty compositeComponent.facets.header}">
  <div class="rich-panel-header #{compositeComponent.attrs.headerClass}">
   <composite:insertFacet name="header"/>
  </div>
</c:if>

However, it does not work. There is a good explanation why it does not work in this article:

http://www.ilikespam.com/blog/c:foreach-vs-ui:repeat-in-facelets

When the c:if test is evaluated the compositeComponent.facets is always empty. Hence, a header is not shown even when it presents. The solution is also in that article. We will use ui:fragment. The final code that is sensible to a header facet is following:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:c="http://java.sun.com/jstl/core"
      xmlns:composite="http://java.sun.com/jsf/composite">
<head>

<title>panel</title>

</head>

<body>

<composite:interface>
    <composite:attribute name="style" required="false"/>
    <composite:attribute name="styleClass" required="false"/>
    <composite:attribute name="headerClass" required="false"/>
    <composite:attribute name="bodyClass" required="false"/>
</composite:interface>



<composite:implementation>
    <h:outputStylesheet name="rich/css/panel.css" />

 <div class="rich-panel #{compositeComponent.attrs.styleClass}"
            style="#{compositeComponent.attrs.style}">

  <ui:fragment rendered="#{! empty compositeComponent.facets.header}">
   <div class="rich-panel-header #{compositeComponent.attrs.headerClass}">
    <composite:insertFacet name="header"/>
   </div>
  </ui:fragment>
 
  <div class="rich-panel-body #{compositeComponent.attrs.bodyClass}" > 
   
   <composite:insertChildren />
  </div> 

 </div>
</composite:implementation>

</body>

</html>
update January 19, 2009:

Today we have been notified that it will be possible to use c:if as well as other jstl like tags for conditional operations inside the templates.

JSF 2.0. Test Drive PDL. Part 1

Posted by Sergey Smirnov    |       |    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: https://javaserverfaces.dev.java.net/ .

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: http://livedemo.exadel.com/richfaces-demo/richfaces/panel.jsf

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>
</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" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:rich="http://java.sun.com/jsf/composite/rich">
<f:view contentType="text/html"/>

<h:head>
    <title>Panel Test</title>
</h:head>

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

 </h:body>

</html>

We use rich: namespace which is defined at the top of the page as xmlns:rich="http://java.sun.com/jsf/composite/rich. In our case, http://java.sun.com/jsf/composite/rich 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"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:c="http://java.sun.com/jstl/core"
      xmlns:composite="http://java.sun.com/jsf/composite">
<head>
 
<title>panel</title>
 
</head>
 
<body>
 
<composite:interface>
    <composite:attribute name="style" required="false"/>
    <composite:attribute name="styleClass" required="false"/>
    <composite:attribute name="headerClass" required="false"/>
    <composite:attribute name="bodyClass" required="false"/>
</composite:interface>
 
 
 
<composite:implementation>
    <h:outputStylesheet name="rich/css/panel.css" />
 
 <div class="rich-panel #{compositeComponent.attrs.styleClass}"
                       style="#{compositeComponent.attrs.style}">
  <div class="rich-panel-header #{compositeComponent.attrs.headerClass}">
   <composite:insertFacet name="header"/>
  </div>
 
  <div class="rich-panel-body #{compositeComponent.attrs.bodyClass}" > 
   <composite:insertChildren />
  </div> 
 
 </div>
</composite:implementation>
 
</body>
 
</html>

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:

.rich-panel{
  border-width: 1px;
 border-style: solid;
 padding : 1px;
 color:#000000;
 font-family:Arial,Verdana,sans-serif;
 font-size:11px;
 background-color:#FFFFFF;
 border-color:#BED6F8; 
}
   
.rich-panel-header{
 padding : 2px;
    border-width: 1px;
    border-style: solid;
 background-color:#BED6F8;
 border-color:#BED6F8;
 font-weight:bold;   
}
 
.rich-panel-body{
 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....

RichFaces 3.3.0 Release: New Components and Features Overview

Posted by Sergey Smirnov    |       |    Tagged as
The Improved Queue The a4j:queue component creates a queue of the Ajax requests. The Ajax4JSF or RichFaces components with built-in Ajax can reference the queue to optimize their Ajax requests. Previous version of RichFaces also provided queue functionality, but there was a number of reasons to develop the queue component and enhance the queue functionality. In the previous versions the queue had quite a simple implementation: it sent to the server only the last Ajax request out of all requests coming in the queue during a request delay...

This is a part of the article posted on JBoss Wiki pages, to read more of it, plz visit this Wiki page

RichFaces 3.3.0 GA Available

Posted by Sergey Smirnov    |       |    Tagged as

RichFaces 3.3.0 could be downloaded here

Documentation for the new release could be checked here

As usual you could check all the new components, features and examples here

This release introduced the next new components:

  • rich:editor

WYSIWYG editor that allows to input the formatted text.

  • a4j:queue

Global/default queues mechanisms is implemented. Separate component for queues definition is created.

Enhancements, Simplifications:

  1. ExtendedDataTable component was reviewed and improved according to the community feedback (was introduced in 3.2.2 in preview state).
  2. Menu Components are improved according to the requests from community. Menu Items now could be used as standalone components. E.g. direct children for the toolbar. issue
  3. Data Table improvement - onRowContextMenu event is introduced according to numerous community requests.
  4. Framework Queue script implementation was fully reviewed and improved additionally to a4j:queue component implementation.
  5. inputNumberSlider vertical layout contributed by the extendedDataTable authors (Many Thanks!)

Code Stability

  1. bug fixing
  2. keeping unit test coverage on a high level.
  3. auto tests (Server and Client). Selenium Test Suite.
  4. control of common quality metrics (PMD/Checkstyle).

Rich Faces 3.3.0.BETA1 Available

Posted by Sergey Smirnov    |       |    Tagged as

RichFaces 3.3.0.BETA1 has been deployed to: http://repository.jboss.org/maven2/org/richfaces/ui/richfaces-ui/3.3.0.BETA1/

So, rich:editor and global queue mechanism including a4j:queue component available for public review within this BETA. So awaiting for community feedback!

RichFaces 3.2.2 GA Available

Posted by Sergey Smirnov    |       |    Tagged as

This release introduced the next new components:

  • rich:beanValidator component
It could be used to register model-based constraints defined Hibernate validators for the component.
  • rich:ajaxValidator component
a4j:support like component which enables validation according to some event on parent component. Also registers model-based Hibernate Validators on parent component.
  • rich:graphValidator component
The component register model-based Hibernate Validators for some subtree. it also could be used in order to fire the whole bean validation including fields which are not used on the page.
  • rich:extendedDataTable component
The component is contributed to Rich Faces from the community. It extends rich:dataTable with additional features - manageable selection of rows, columns reordering, grouping by columns and etc..
  • rich:hotKey component
Component is implemented on the top of jQuerry hotKey plugin. It allows to register JS callbacks on some hot keys as for the page either as for separate components.

Also the next new features available starting from this release:

  • State Manager API component
It allows to define set of states for the page and navigate between these states using standard JSF navigation.
  • Tree Drag and Drop API component
TreeAPI extended in order to provide convenient D'n'D feature usage as inside the Tree either as between the trees and other page components

Usefull guidelines and samples created:

  • DarkX and GlassX skins created using plug'n'skin feature
Step by step components creation guideline with general CDK features explanations available together with the RF developer guide.
  • Samples and articles for all the new features and components mentioned above are also created and available online.

You can download 3.2.2 GA from the official download page at Rich Faces downloads

Thank you everyone who posted feedback on the RichFaces forum and submitted jira issues.

Rich Faces 3.2.2 Beta 1 and Beta 2

Posted by Sergey Smirnov    |       |    Tagged as

We've started to build 3.2.2 betas.

Beta 1 can be found at:

http://repository.jboss.org/maven2/org/richfaces/ui/richfaces-ui/3.2.2.BETA1/

And Beta 2 has been deployed to:

http://repository.jboss.org/maven2/org/richfaces/ui/richfaces-ui/3.2.2.BETA2/

New features list can be found at

Our wiki

Short list of new features:

  • validation components
  • hotKey component
  • state management API
  • Tree drag and drop API

Examples can be found in SVN in trunk samples folder. The richfaces-demo examples are also commited as drafts to svn.

back to top