Help

Archive

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.

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.

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/

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.

16. Jan 2009, 02:16 CET, by Sergey Smirnov

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....

Showing 1 to 5 of 13 blog entries