Red Hat

In Relation To Rich Faces

In Relation To Rich Faces

JSF 2.0. Test Drive PDL. Part 3. Resources

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

seam-gen gets a modest upgrade

Posted by    |       |    Tagged as Releases Rich Faces Seam

Along with Seam 2.1 comes a handful of enhancements to seam-gen. These changes are a culmination of the mods I made to the seam-gen project that forms the basis of the sample code for Seam in Action. Perhaps after reading this entry, you'll conclude that the enhancements go well beyond modest.

The improvements to seam-gen can be classified into four categories:

  • look and feel
  • functional
  • project structure / build
  • seam script

Since we're all attracted to shiny new things, let's start with the style upgrades and supplement the discussion with some screenshots.

Freshening up seam-gen's look

Both RichFaces and ICEfaces seam-gen projects already carry a touch of elegance thanks to the component styling controlled via CSS-based themes (i.e., skins) bundled with the two libraries. The styles that get imported with a theme are most apparent in the rich layout components from the JSF component sets (e.g., <rich:panel> and <ice:panelTab>). But there are some areas of the page that don't get coverage, such as the form elements and status messages. I figured out a way to stretch the theme across the whole page using RichFaces' theme extensions and some better default styles (unfortunately, the theme extensions only apply to RichFaces projects at this point).

Although it may seem trivial to worry about how the application looks, these style improvements are an important first step to ensuring that your application looks more presentable down the road (giving you one less thing to worry about early on in the project).

Extending the RichFaces skin

RichFaces uses skins to decorate its built-in components. But what's neat is that this skinnability feature is left entirely open to extension. A skin is nothing more than a message bundle that maps colors and font sizes to key names (e.g., panelBorderColor). Each rich component (e.g., <rich:dataTable>) is bundled with dynamically generated CSS that references these key names to style the component according to the theme.

The CSS is generated from an XML-based CSS file, which uses the file extension .xcss. The syntax used in this file consists of both standard and special skin-aware elements and attributes that translate into CSS. To extend the theme, you simply create a custom .xcss file and import it into your page using <a:loadStyle> from the Ajax4jsf component set. If you need to customize the colors and font sizes, or even add an additional skin property, you simply create a file named %SKIN_NAME%.skin.properties and place it at the root of the classpath. You replace %SKIN_NAME% with the name of the RichFaces skin (e.g., emeraldTown).

Details, details, details. Where's the benefit? Well, through the power of CSS, we can make non-RichFaces components look rich! And it's not just about colors, either. It's even possible to generate gradient images using one of the special elements in xcss (<f:resource>). That means we can make slick looking form elements. In seam-gen projects, these additional theme-related styles are defined in the file theme.xcss, which sits adjacent to the existing theme.css file. Here's a snippet from that file which styles text inputs:

<u:selector name="input[type=text], input[type=password], textarea, select">
  <u:style name="background-color" skin="controlBackgroundColor"/>
  <u:style name="color" skin="controlTextColor"/>
  <u:style name="background-position" value="left top"/>
  <u:style name="background-repeat" value="repeat-x"/>
  <u:style name="background-image">
    <f:resource f:key="org.richfaces.renderkit.html.images.SliderFieldGradient"/>
  </u:style>
  <u:style name="border" value="1px solid"/>
  <u:style name="border-color" skin="tableBorderColor" />
</u:selector>

Here's the CSS that this XML markup produces (for the DEFAULT RichFaces theme):

input[type="text"], input[type="password"], textarea, select {
  background-color:#FFFFFF;
  background-image:url(/appname/a4j/g/3_2_2.GAorg.richfaces...SliderFieldGradient...);
  background-position:left top;
  background-repeat:repeat-x;
  border:1px solid #C0C0C0;
  color:#000000;
}

And here's how an input generated by a plain old <h:inputText> would look:

Keep in mind that the input's style is going to coordinate with the RichFaces theme. That's true of all form elements as well as the general font color and the color of links. See for yourself in the next section.

Showing off the new look

Below is a collection of screenshots, which are taken from a seam-gen project generated from the vehicles schema used for testing seam-gen. These screenshots show off the new styles as they look with various RichFaces themes. The RichFaces theme is controlled using the org.richfaces.SKIN servlet context parameter defined in web.xml:

<context-param>
  <param-name>org.richfaces.SKIN</param-name>
  <param-value>classic</param-value>
</context-param>

The first thing you'll notice when you deploy a seam-gen 2.1 project is that there is a new home page featuring the Seam logo. Beyond that, you should simply notice that the elements on each page below all coordinate with the selected theme.

You'll notice in these next two screenshots that I have customized the status messages, also true for ICEfaces projects. An appropriate icon is used in front of each status message according to its level (warn, error, and info). While working on this enhancement, I fixed JBSEAM-1517 so that the messages look presentable and don't overlap. (Believe it or not, the messages were still using the orange style from the original seam-gen, which didn't match at all with the RichFaces or ICEfaces theme).

The cherry on top of all this is the favicon of the Seam logo, which is defined in the main Facelets template and appears in the URL location bar. I think this is the sweetest enhancement because it gives you that pride that you are using Seam.

The only downside of the new theme is that the Visual Editor in JBossTools doesn't understand the xcss file. That's why I left behind an improved version of the theme.css file, which is still used in the main Facelets template. In it, I define static CSS styles that don't rely on the skin properties. It certainly would be cool if the Visual Editor could interpret the xcss file as it would make developers more productive when extending the RichFaces theme. Currently, after making a change to the xcss file, you have to do a hard restart of the application to get RichFaces to reload the generated CSS (and with some browsers you also have to clear out the browser's cache).

That's enough about styles for now. There are a couple other enhancements to the application's presentation that fall more along the lines of functional, so we'll look at those next.

Just what the boss ordered

As I talk about enhancements to seam-gen, it's important to keep in mind the purpose of seam-gen so we don't lose perspective. seam-gen provides two key services:

  1. A starting point for developing with Seam, saving you from getting started tedium
  2. A broad demonstration of Seam features that you can begin building on

seam-gen is not going to do your job for you. With that said, there were a lot of areas of inconsistency in the generated project and other things that seam-gen could do better. Here's a list of functional changes that were made to seam-gen projects, which were mostly developed to satisfy requests that trickled down from management:

  • Human-readable labels are generated from property names using a camel-case translation (i.e., camelCase => Camel case)
  • The proper converter is applied whenever outputting the value of a property (e.g., date, time, number)
  • Icons are used in the tabs on the detail pages to denote parent and child associations
  • The markup for the sort links in the column headers on the listing pages is simplified using a Facelets composition template
    <ui:include src="layout/sort.xhtml">
      <ui:param name="entityList" value="#{personList}"/>
      <ui:param name="propertyLabel" value="Name"/>
      <ui:param name="propertyPath" value="person.name"/>
    </ui:include>
  • Client-side sorting of columns in the child association table is enabled on the detail pages (leveraging the RichFaces table)
  • Activated sorting on the listing page for properties on a component or composite key (e.g., vehicle.id.state)
  • JPQL used for sorting is now compliant
  • Added a link in each row on the listing page to edit the record (previously only possible from detail page)
  • Changed the default username to admin, still allowing any value for the password. The failure login scenario can now be triggered out of the box.
  • One-to-one associations are linked up in the UI the same way as many-to-one associations
  • Introduced a head named insertion in the main Facelets template (view/layout/template.xhtml) for adding additional markup to the <head> element on a per-page basis
    <ui:define name="head">
      <script type="text/javascript">
        window.onload = function() { ... }
      </script>
    </ui:define>
  • Moved the <h:messages globalOnly="true"> declaration to the main Facelets template and conditionally check a Facelets parameter named showGlobalMessages to turn them off on a per-page basis
  • The conversation is not propagated by links in the main menu bar (i.e., propagation="none")
  • Added a button to reset the search on the list pages
  • The entity manager is switched to manual flush mode when editing a record
  • A UI command link was added to to the debug page for destroying a selected conversation (not specific to seam-gen)

I'm sure there are other small enhancements that I am forgetting about, which I will leave for you to discover. Let's move on to the project structure and build changes.

Semantically speaking

seam-gen projects are still built using Ant and they still have fundamentally the same (quirky) structure. What I did, though, was fix a semantic error. I changed the source directories so they better reflect how they are built rather than what classes they contain. In Seam 2.0, the two main source directories were:

  • src/action
  • src/model

Components in src/action were added to hot deployable classpath when running in development mode, whereas components and regular classes in the src/model directory ended up on the main (static) classpath. In production mode, of course, the resources in these two directories both would end up in the same classpath. The problem is that hot deployable components are not necessarily action components and non-hot deployable components are not necessarily model classes. To fix this semantic mixup, the source directories are now:

  • src/hot
  • src/main

I trust that you can immediately grasp the purpose of these two source directories and thus feel more comfortable finding a place for the class you are about to create. Unfortunately, JBossTools still uses the old convention for the time being. Despite the difference, it has no problem consuming a seam-gen project with the new folder names since, internally, it relies on a mapping between folder name and function (seam-gen prepares the mapping configuration to reflect this new convention).

Naturally, the project build script was updated to accommodate the new names for these source directories. But there are several other changes that came out of my meddling with the build.

More muscle under the hood

First and foremost, tests which extend SeamTest can now be run using Java 6! This was a huge frustration for me and I am thrilled to have worked out a solution. The issue is really that the Embedded JBoss container is sorely out of date and flakes out on Java 6. Until a newer version of Embedded JBoss is ready, the workaround is to use and endorsed JAR file to fix a conflict with JAX-WS and to allow a special array syntax specific to the Sun JDK. You can check the test target in the build file for the specifics.

Fans of Groovy will be excited to learn that it's now possible to use Groovy components in EAR projects. The EAR project build compiles Groovy scripts on the classpath using groovyc, making them bona fide Java bytecode. (Getting seam-gen EAR projects to interpret .groovy files at runtime requires some more research). But what's even more exciting is that you can now write tests in Groovy (again compiled using groovyc) and test components written in Groovy. Really, this was just a matter of putting the build logic in place, but it's still important to know that you can get the Groovy support right out of the box. There's still work to be done to make the support for Groovy more elegant, but for now it is at least comprehensive.

Here's a bunch of other goodies that were thrown into the build:

  • seam-gen WAR projects now have a consolidated compile target
  • two new targets, reexplode and redeploy, execute clean unexplode explode or clean undeploy deploy, respectively
  • the restart target now detects if you have deployed an exploded or packaged archive and restarts the application appropriately (before it bombed if you had a packaged archive deployed)
  • the view folder is added to the classpath during the execution of tests so that page actions defined in fine-grained page descriptors (i.e., .page.xml) get invoked properly (previously tests only read the global page descriptor (i.e., pages.xml)
  • a new target named javadoc generates JavaDoc API from the project source

If you are interested in getting the dependencies of a seam-gen project under control, check out my article about how to manage the dependencies of a seam-gen project with Ivy.

That wraps up just about all the changes to seam-gen projects. All in all, what these upgrades should do is make your demos of Seam look just a touch prettier and give you more hammers to swing during development. Obviously, there are still plenty of improvements that could be made, so feel free to contribute them. Patches generated with svn diff are preferred.

In the final section, I want to talk about the changes that were made to the seam script and the different ways that it can now be invoked.

Removing the shackles from seam-gen

The seam script (which we all call seam-gen) has finally been set free. In the past, the seam script hasn't been as comfortable to use as other project generation tools, such as Grails, because the developer has been locked into having to execute it from a Seam distribution directory. The approach that Grails takes is to add the location of the grails script to your PATH, set GRAILS_HOME, and use the script like a system command. I have an approach that falls somewhere in between and that I believe is more flexible.

Thanks to changes in the bootstrap script, you can now run seam out of any directory on the computer and it will work as it does today (meaning your current working directory can be anywhere). The seam script still has to reside in a Seam distribution directory or the SEAM_HOME environment variable must be set if it doesn't, but now you have a third option of creating a symlink to the seam script from a directory already on your path (such as ~/bin). Internally, the script figures out your current directory and the SEAM_HOME environment variable relative to the location of the script (there is no reason to make the developer set the SEAM_HOME environment variable, though it's still honored if present). More on the current working directory in a second. The point so far is that the seam script is going to work from anywhere. No more silly restrictions.

As a side note, I want to mention that I added a validation check in the bootstrap routine that verifies the user has the JAVA_HOME environment variable defined and that it resolves to a valid JDK installation. Otherwise, the Ant build is going to fail anyway.

Ever since Seam 2.0, the seam create-project command has been moving the build.properties that holds the responses from seam setup to the file seam-gen.properties in the root of the project. But we haven't done anything with this file yet...until now. Here's the big enhancement (the one you have all been asking and waiting for).

If your current working directory has a seam-gen.properties file AND and build.xml file, then the seam script recognizes that you are in a seam-gen project and operates using the seam-gen.properties file in that directory rather than the seam-gen/build.properties in the Seam distribution. If you put the seam script (or a symlink to the seam script) on your PATH, then you can simply enter a project and run seam generate. If the seam script is not on your PATH, then you have to run something like ~/projects/seam-2.1.0.GA/seam generate. It really doesn't matter how it is invoked. This works across the board on Linux, Windows, and Mac. (By the way, writing cross platform scripts is a huge pain).

When your current directory is a seam-gen project, you essentially have the choice of using the seam script or the ant command to run the targets. The seam script is beneficial if the ant command is not on your PATH, though if you have Ant installed, then the seam script is just a middleman. That is, unless you are executing a code generation target (e.g., new-form, generate). Then you do need to use the seam script.

So there you have it, you can now use seam-gen to manage multiple projects and you can execute code generation from within the project! But wait, there is even more! If you don't yet have a seam-gen project created, you can feed a properties file of your choice into the script using the -Dseam-gen.properties flag:

seam -Dseam-gen.properties=seam-gen/myproject-build.properties

The value of the property must either be an absolute file path or a path relative to the root of the Seam distribution. You can also override the location of the seam-gen directory or even just the seam-gen templates (if you keep a customized version) using -Dseam-gen.dir and -Dtemplates.dir, respectively. It may be a little obscure to have to pass -D flags to the seam script, but it gives you the power you are looking for.

I hope you're excited about all the enhancements that I presented in this article and that it helps you to become more productive with your seam-gen projects. There is still work to be done, including a major refactoring of the seam-gen build system, which I am going to start documenting on this wiki page. But for now, you should have plenty of new toys to play with.

Developing Portlets using JSF, Ajax, and Seam

Posted by    |       |    Tagged as Rich Faces Seam

Rich Faces 3.2.1 released

Posted by    |       |    Tagged as Rich Faces

This release introduced next new features and improvements:

  • Plug'n'Skin feature introduced
This feature allows fast and convinient predefined skins customization and new skins based on predefined ones creation.
  • Demo laguna skin created using plug'n'skin
An example of skin created using plug'n'skin added to demosite
  • Suggestion Box improved
This API gaves possibility to save selected objects instead of strings in some hidden fields for further processing. And also API for calling suggestion added(for comboBox like usage)
  • Sorting futher improvements (Sorting objects not strings)
Now built-in dataTable sorting uses objects sorting so additional comparators not needed anymore for simple sorting functionality implementation. Also some issues reported by the community resolved
  • Filtering further improvements
Default input corrected and styled. Also some issues reported by the community resolved
  • DataScroller improvements
Multiple instances behaviour and page bindings corrected. Incorrect page after model changes handling added.
  • componentControl and contextMenu attachement improvements
Problems with attachements to DOM elements solved

Also next bugfixes reported by the community was performed:

  • dataTable issues (including sorting, filtering features)
corrections on decode
  • scrollableDataTable fixes
Scrolling and loading data problems, cross-browser support fixes

  • ComboBox numerous fixes
  • File Upload improvements and fixes
  • Character encoding problems
  • Memory leaks and perfomance fixes
  • MyFaces specific fixes
  • Opera browser support fixes

You can download 3.2.1 GA from the official download page at http://www.jboss.org/jbossrichfaces/downloads/

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

RichFaces. How do you see it in the future?

Posted by    |       |    Tagged as Java EE Rich Faces

Based on the feedback from the community (RichFaces Forum) and the RedHat/JBoss support team, we can emphasize four possible major directions:

  1. Developing new components to continuously extend the component set
  2. Simplifying the development with JSF and RichFaces
  3. Keeping RichFaces constantly stable
  4. Making RichFaces modern and cool

What are your personal preferences. Vote for one of the options at:

http://jboss.com/index.html?module=bb&op=viewtopic&t=134778

RichFaces 3.2.0 SR1 has been released

Posted by    |       |    Tagged as Java EE Rich Faces

We have released the SR1 for RichFaces 3.2.0. This service release closes the most critical issues reported by community. The list includes:

  1. Correct work with I18N text
  2. Fixed problem with use of 'binding' attribute in case of JSP environment
  3. Enabled use of special chars for new components such as inplace input and select, comboBox
  4. Fixed problem with push component under Facelets - eventProducer method that won't get invoked
  5. Fixed problem with using the horizontal scoll bar for scrollableDataTable component
  6. Fixed problem when scroller listener in datascroller isn't fired
  7. Fixed problems of new components(inplaces, comboBox) in concurrent environment
  8. Fixed problem of symbols escaping between edit/view states in inplaces

The release notes for RichFaces 3.2.0SR1 is available at: http://wiki.jboss.org/wiki/RichFacesWhatIsNewIn3_2_0SR1

You can download 3.2.0SR1 from the official download page at http://www.jboss.org/jbossrichfaces/downloads/

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

RichFaces 3.2 released

Posted by    |       |    Tagged as Rich Faces Seam

RichFaces 3.2.0.GA is out!

This release introduces the following new components:

  • Combo Box
  • Inplace Input
  • Inplace Select
  • Progress Bar
  • File Upload
  • Columns
  • Pick List

Along with these enhancements:

  • DataTable Sorting
  • DataTable Filtering
  • Calendar month and year manual selection
  • Objects selection for suggestion box
  • Standard component skinning
  • Client-side EL functions: rich:clientId(Id), rich:element(Id), rich:component(Id)

RichFaces 3.2 requires JSF 1.2 and JDK 5.0 or above.

You can try out a demo of the new components here.

Congratulations to the RichFaces team!

RichFaces 3.1.3 released

Posted by    |       |    Tagged as Rich Faces

Updated - added in <rich:orderingList /> and specify the locale for the calendar

The RichFaces team have released RichFaces 3.1.3.GA. This is the first release since 3.1.0 back in September to include any new components (both 3.1.1 and 3.1.2 were bug fix releases) so I wanted to highlight the key improvements for you.

Time Picker

What's really great about the RichFaces timepicker is that it is integrated into the calendar control - you can easily choose to provide a graphical control for the date, the time or the date /and/ the time This is really easy to use - just bind the calendar control to the model as usual
<rich:calendar value="#{flight.departureDate}"
               locale="#{locale}"
               datePattern="dd/M/yy hh:mm" />
As you can see, it's also fully internationalisable!

Controlling one component from another

<rich:componentControl /> allows you to fire an action on another component when a javascript event occurs on your current component. This is very powerful, and perhaps hard to understand until you need it, so lets look at a very simple example. Here we have a modal panel (a bit like a css/div based popup), which we want to launch from somewhere in our page:

<rich:modalPanel id="panel" width="350" height="100">
  <f:facet name="header">
    <h:outputText value="Modal Panel" />
  </f:facet>
  <h:outputText value="This panel is called using rich:componentControl"/>
</rich:modalPanel>
<h:outputLink value="#">
  Show Modal Panel
  <rich:componentControl for="panel" attachTo="link" operation="show" event="onclick"/>
</h:outputLink>

Rather than having to call some JS function, we can just attach a component controller to the link, and tell it what operation to call on what component.

<rich:componentControl /> can do a lot more than this - take a look at the online demo for ideas.

Shuttle list

As I've come to expect from the RichFaces guys, a really slick looking control, it's also simple to use:
<rich:listShuttle sourceValue="#{items.availableItems}"
            targetValue="#{items.selectedItems}" 
            var="item"
            sourceCaptionLabel="Available Items"
            targetCaptionLabel="Currently Active Items">

  <rich:column width="18">
    <h:graphicImage value="#{item.icon}"/>
  </rich:column>
  <rich:column>
    <h:outputText value="#{item.label}"/>
  </rich:column>

</rich:listShuttle>
Notice how we've embedded other rich components to layout the lists!

Orderable list

Another similar component is the orderable list. Here's how you use it:
<rich:orderingList value="#{myMusic}" var="album">

  <rich:column>
    <f:facet name="header">
      Song Name
    </f:facet> 
    <h:outputText value="#{album.title}"/>
  </rich:column>

  <rich:column>
    <f:facet name="header">
      Artist Name
    </f:facet>
    <h:outputText value="#{album.artist.name}" />
  </rich:column>

</rich:orderingList>

Context sensitive menu

RichFaces already has components for rendering a menu bar, and 3.1.3 adds a right-click menu.
<s:div id="flower">
  <h:graphicImage value="flower.jpg"/>
  <rich:contextMenu event="oncontextmenu" 
                    attached="true" 
                    submitMode="none">
    <rich:menuItem value="Zoom In" 
                   onclick="enlarge();"/>
    <rich:menuItem value="Zoom Out" 
                   onclick="decrease();"/>
  </rich:contextMenu>
</s:div>
Here we've attached the context menu to the parent <s:div /> component, so any right click on it causes the menu to show.

There's also

  • Big improvements to Portal support (we are just finishing off support for Seam and RichFaces in a portlet)
  • A system for customising how styles are loaded (one big lump, or on demand)
  • Over 180 bug fixes (see the release notes)

Congratulations to the RichFaces team!

back to top