RichFaces 4.1.0.Final Release Announcement

I’m thrilled to announce the release of RichFaces 4.1.0.Final. It’s been a long road from 4.0 to 4.1, with a significant train of milestone releases along the way. The journey was worth it though, with a significant 4.1 release building on top of the successful 4.0.0.Final release, providing: additional components migrated from the RichFaces 3 component set, altogether new components, and significant enhancements to the framework feature set.

To try out this release you can download the distribution directly, or for maven users increment the RichFaces version in your pom.xml to 4.1.0.Final. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Let’s dive in, and look at some of the details of what’s new in RichFaces 4.1!

New Components

We’ve delivered a number of new components in this release:

• rich:editor
• rich:pickList
• rich:orderingList
• rich:notify

Not only have we migrated forward more RichFaces 3.x components, but we’re also providing an altogether new component - the notify component - put together by Bernard Labno, a RichFaces community member.

Mobile Compatible Components
We’ve leveraged HTML 5 and CSS 3 to create a set of resources that make the existing RichFaces components mobile compatible. Check out the results yourself in our mobile showcase with your webkit-based mobile phone, (or checkout the mobile showcase directly with your desktop browser).

We’ve put together a comprehensive guide detailing how you can take advantage of this approach with your own applications, and deliver a modern mobile application today - leveraging your existing skillset and investments in both JSF and Richfaces.

Not all the components make sense in a mobile environment, and not all mobile browsers are equally capable. Be sure to also take a look at our mobile design document, outlining the choices and compromises we had to make.

Showcase
Along with this new mobile face, the Richfaces showcase has undergone a number of additional significant changes.

We’ve deployed the showcase to OpenShift, Red Hat’s PasS offering. The OpenShift Java EE 6 support provides a great platform to take your application all the way from development with Express (free!) to production with Flex (highly scalable!). For the RichFaces project, this gives us the chance to showcase our components in a Java EE environment, where our framework really shines!

We’ve also included samples for the new components listed above, as well as a rich:push component sample, keeping it straightforward to incorporate advanced RichFaces components in your application. Lastly, a number of bug fixes and simple improvements throughout the showcase have overall improved the user experience of the showcase itself.

Individual component improvements
I’d like to single out a few component enhancements from this release:

rich:push

Push has been de-coupled from JMS, allowing RichFaces users to take advantage of push technology in non-JMS (ie. servlet) environments.

A CDI API has been provided for firing push events - aligning the push component with the standardized Java EE programming model

rich:fileUpload

Some events that were missing from the 4.0 release have been added, including the onclear event

drag and drop

A bug with dynamically rendering of drag sources and drop targets has been resolved, improving drag/drop functionality in components like the rich:tree

rich:extendedDataTable

For those creating RichFaces skins, you’ll be happy to hear we replaced the cellpadding and cellspacing attributes of the extended datatable with CSS equivalents, allowing skins to override the values

For a complete listing of issues resolved, refer to the release notes of each of the milestone releases: 4.1.0.M1, 4.1.0.M2, 4.1.0.M3, 4.1.0.M4, 4.1.0.CR1, 4.1.0.CR2, 4.1.0.Final

Resource packaging
Another great feature with this release is the Resource packaging and minification. An absolute necessity when developing for mobile applications, this feature can provide performance improvements to your desktop applications as well by dramatically reducing the number of javascript and CSS files the browser client has to download. Read the docs to see how you can activate this for your applications.

For those looking for the RichFaces 3 LOAD_NONE capability, you can use this resource minification configuration to achieve the same results.

Source hosted on github
A significant achievement early in the 4.1 development process was the migration of our source code version control system from svn to git, specifically hosted on github.com. We noticed significant advantages to using git, both within our team, and in our collaboration with community members. Git’s ability to enable a sophisticated workflow, and encourage community contribution in the form of pull requests has made “bit management” a pleasurable task.

Other noteworthy items
It’ worth pointing out that RichFaces 4.1 ships with an updated jQuery release (v. 1.6.4). Keeping the jQuery release version up-to-date facilitates RichFaces inter-operability with other jQuery plugins.

RichFaces 4.1 works with a number of modern browsers, however it currently requires Internet explorer 9 to be run in compatibility mode, due to an upstream mojarra issue.

Documentation
Lastly, I’d like to remind everyone of the availability of the RichFaces documentation:

• Developer guide
• Component reference
• VDL tag library doc
• javadoc
• Showcase
• Wiki
• Browser compatibility matrix

These docs are a great resource detailing how to make use of the RichFaces framework in your application. They are however an ongoing effort, with some specific areas that need improvement. Specifically we need to flesh out the descriptions of the VDL tag library doc (note: the attribute listing is complete), and we need to vet the migration guide. This is a great way to get involved, should you want to contribute to the project!

Looking Forward
In a recent blog post, I laid out a strategy for the future of the RichFaces project, and extended an invitation to all who would like to have a say in future directions in our development forum. While RichFaces 4.1 undoubtedly provides some great fixes and features, we are excited about the future direction of the project, and what we can offer moving forward!

State of the RichFaces

With a RichFaces 4.1.0.Final release on the horizon, now is a good time to talk about the future of the project. Let me start by announcing that I will be taking over from Jay Balunas as lead of the RichFaces project. Jay has been a long-time shepherd of RichFaces from within JBoss, and has had a direct hand in making the project such a great success. Jay has been a terrific mentor and while he is stepping down as the project lead, he will continue to stay involved, sharing his insight and experience with the Richfaces team. He will just no longer get the final word ;)

Moving forward, I would like to see the project continue to focus on the key strengths that have made RichFaces such a great project to be involved with: innovation, open standards, community, and quality.

Innovation

RichFaces has long been the place to come for JSF innovation. Never content to simply provide a JSF component set, the RichFaces project (together with other JBoss projects) has always aimed to provide developers with a complete JSF framework for developing applications. Some of these innovations include:

• Pioneering JSF ajax support
• Client side validation
• Ajax Push component - leveraging websockets where available
• The CDK (Component Development Kit) - in RF 4 the CDK builds on top of the JSF 2 composite components feature
• Support for mobile browsers in our base component set
• Resource packaging and minification
• Advanced queuing
• Sophisticated tooling support (together with JBoss tools)

Open Standards

Richfaces has played a significant role in improving the JSF specification with contributions to JSF 2.0, particularly in the area of ajax integration. RichFaces also aims to improve the standards story by integrating JSF with other Java EE standards in some of the same innovations mentioned above:

• Client side validation brings Bean Validation into the client environment
• The push component couples JMS messaging with our JSF component set
• The push component also leverages CDI, providing building on the standardized Java EE programming model

Community
RichFaces is also very much a community oriented project. Both our development and planning efforts are done out in the open, with an open door to anyone who wants to help out. Some of the ways we actively work to facilitate community interaction include:

• A user forum with an incredible amount of traffic
• Weekly team meetings held openly in IRC
• A developer forum - where new ideas for the framework are worked out
• Active use of social media (twitter, Google+)
• Github hosting - facilitating community contributions

Quality
RichFaces is a very well tested project, with a dedicated QE team that continually writes new tests for the framework, and ensures that existing tests continue to pass in their automated runs. Look forward to some upcoming blog posts, where we will expand on our testing strategy, and speak to the industry leading role JBoss is taking with projects like Arquillian, JSFUnit, and how we build on that with RichFaces. This all comes together in a robust, enterprise-ready platform on which you can develop and deploy your applications.

Moving Forward
Moving forward we plan to keep up this pace of innovation with our 4.Next efforts. The existing component set is crucial to the project, and will continue to see new improvements and additions - but we need a new vehicle to deliver new components faster and more effectively. We would like to be able to better leverage the mountain of work done in other OSS projects in the javascript component space, and facilitate contributions from prospective contributors looking to implement their own “critical components”. To this end, we are proposing the addition of another component set in the RichFaces project.

This new component sub-project will leverage existing javascript code where possible, either directly, or by composing them into new components. Where use cases require, we will continue to develop new components, contributing back to upstream javascript projects wherever possible. This idea is currently at a proposal stage, with a proof-of-principle demonstrated my recent CDK blog series. Join us in the developer forums, as we work out the details of how to build this next-generation component set.

Thanks to all of you for your interest and contributions to the project, feel free to ping me in the forums, IRC (in #richfaces), twitter or anywhere for that matter should you want to discuss how you can contribute to the project, and help shape it into what you need it to be!

RichFaces 4.1.0.CR2 Release Announcement

We are announcing the release of RichFaces 4.1.0.CR2, a second release candidate for RichFaces 4.1. We had a couple of regressions that were introduced in the 4.1.0.CR1 release that we’ve addressed in the with this CR2 release. The expectation is that CR2 will be re-tagged and released as 4.1.0.Final, provided no blocking issues are found. Our QE team has done a great job running their test suite against this release, but I encourage as many community members as possible to download the CR2 release, and make sure it’s “up to snuff”!

To try out this release, you can download the distribution directly, or for maven users increment the RichFaces version in your pom.xml to 4.1.0.CR2. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Noteworthy changes
In addition to addressing the above regressions, our CR2 release has addressed a couple other noteworthy issues.

• showcase tweaks: improving the user experience on both desktop and mobile
• archetype improvements: including the addition of an option for creating a mobile project
• skins: warning messages had an unreadable color on a white background - (warningColor) [RF-11673]
• rich:inplaceInput: a fix for client side validation [RF-11633]
• rich:dataTable: a fix for a regression effecting component decoding [RF-11675]
• rich:calendar: a fix for a regression selecting dates in the popup [RF-11677]
• rich:pickList: a bug converting java arrays when used as backing beans [RF-11680]
• rich:fileUpload: A bug where the list of files in the event omitted the submitted files [RF-11744]
• rich:extendedDataTable: removed cellpadding/cellspacing from EDT, replaced with appropriate CSS [RF-11759]

Please test drive this second release candidate, and give us your feedback in either the forums or with our issue tracker. We’ll soon have a 4.1.0.Final release we all can be proud of, for the work we put into it as a community!

RichFaces 4 CDK | jQeury UI Tabs

Following on with another entry in my CDK series, this time we will look at at creating a pair of components to wrap the jQuery UI tabs plugin with the RichFaces CDK. It'll take two components to accomplish this; one component to define the tab container, and another to define the tabs themselves. Let's dive right in with a look at the Abstract component definitions.

As always, if you are interested in following along in your IDE, you can get the code below on github.

The Component Classes

AbstractTabs.java

package ca.bleathem.richfaces.jquery.component;

import org.richfaces.cdk.annotations.*;

import javax.faces.component.UIComponent;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashSet;
import java.util.List;
import java.util.Set;

@JsfComponent(
        type = "ca.bleathem.richfaces.jquery.Tabs",
        family = "ca.bleathem.Tabs",
        renderer = @JsfRenderer(type = "ca.bleathem.jquery.TabsRenderer"),
        tag = @Tag(name="tabs"))
abstract public class AbstractTabs extends javax.faces.component.UIPanel {
}

Here we have the component class for tor the tabs tag - this will be the container for the tab components that follow. This is strikingly similar to the earlier AbstractHello component we saw in our first CDK example. The component class is serving as a placeholder to define the component properties (type, family, tag) , and the renderer associations. Look back through the previous blogs in this series if you don't recognize these properties.

AbstractTab.java

package ca.bleathem.richfaces.jquery.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.jquery.Tab",
        family = "ca.bleathem.Tab",
        renderer = @JsfRenderer(type = "ca.bleathem.jquery.TabRenderer"),
        tag = @Tag(name="tab"))
abstract public class AbstractTab extends javax.faces.component.UIPanel {
    @Attribute
    public abstract String getTitle();
}

The component class for the tab tag is similar to the one for the tabs tag, adding a definition for a title attribute, and with slightly different component properties. Let's move on from these mundane component definitions and look at the Renderers, where things get more interesting.

The Renderers
Looking first at the simpler tab renderer:

tab.template.xhtml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el"
        xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
        xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core"
        xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.jquery.renderkit.TabRenderer</cdk:class>
        <cdk:superclass>org.richfaces.renderkit.html.DivPanelRenderer</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.jquery.TabRenderer</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        <div id="#{clientId}" class="rf_jq_tab">
            <cdk:body />
        </div>
    </cc:implementation>

</cdk:root>

This renderer is simple, again comparable to the hello.template.xml. The new piece we've introduced is the <cdk:body /> tag. This tag indicates where we want to render the contents of the component. So any content (or child components) we nest in out tab tag will be wrapped by the div tag.

We'll see this <cdk:body /> tag again when we look as the (slightly more complex) tabs renderer:

tabs.template.xhtml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el"
        xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
        xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core"
        xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.jquery.renderkit.TabsRenderer</cdk:class>
        <cdk:superclass>org.richfaces.renderkit.html.DivPanelRenderer</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.jquery.TabsRenderer</cdk:renderer-type>
        <cdk:resource-dependency name="" />
        <cdk:resource-dependency library = "javax.faces" name = "jsf.js" />
        <cdk:resource-dependency name = "jquery.js" />
        <cdk:resource-dependency library = "com.jqueryui/css/ui-lightness" name = "jquery-ui-1.8.16.custom.css" />
        <cdk:resource-dependency library = "com.jqueryui/development-bundle/ui" name = "jquery.ui.core.js" />
        <cdk:resource-dependency library = "com.jqueryui/development-bundle/ui" name = "jquery.ui.tabs.js" />
    </cc:interface>

    <cc:implementation>
        <div id="#{clientId}" class="rf_jq_tabs">
            <ul>
                <c:forEach items="#{component.children}" var="child">
                    <li><a href="##{child.clientId}">#{child.attributes['title']}</a></li>
                </c:forEach>
            </ul>
            <cdk:body />
        </div>

        <script type="text/javascript">
            jQuery(function() {
                $(document.getElementById('#{clientId}')).tabs();
            });
     </script>
    </cc:implementation>

</cdk:root>

This renderer template introduces a number of new concepts. For one, you might have noticed I didn't create a RenderBase class, like we did for the datepicker component. We could have, but I wanted to demonstrate that it's not strictly necessary. The CDK allows one to replace the @ResourceDependency annotations we used in the DatepickerRenderBase, with a CDK tag: <cdk:resource-dependency />. This is a one-for-one replacement for the annotation, with matching attributes (in fact, the CDK creates actual @ResourcesDependency annotations in the generated java code). This allows us to define all the required javascript and css resources required by the component in the renderer template itself.

We've also made use of the jstl core EL expressions to execute some logic in our renderer. You can see we loop over each of the children of the tabs component, which will be our tab components. For each child tab, we create an entry in an unordered list with the title attribute of the tab. This isn't just some arbitrary html, we are fulfilling the contract of the jQuery UI tabs plugin. The plugin is going to look for this specific markup to render the tab components, and attach the necessary behavior.

Following the unodered list, we see the <cdk:body /> tag. This renders the child components, delegating to the render associated with each child. In this case, the children are the tab components and will be rendered using the tab renderer from the above tab.template.xhtml template.

The last piece of this template is the javascript call, where we invoke the jQuery UI tabs plugin to enable the client-side behavior. We aren't passing any options to the plugin in this example, but we could easily do so using the scriptOption CDK tag demonstrated with the datepicker component.

The Result
So what does it look like when we put it all together?
With this sample markup:

<b:tabs>
    <b:tab title="Tab 1">
        Hello <b>Tab</b>!!
    </b:tab>
    <b:tab title="Tab 2">
        With nested components:
        <br />
        <b:datepicker value="#{myBean.value}" dateFormat="yy-mm-dd" showOn="both" buttonImageOnly="true" /> <br />
    </b:tab>
</b:tabs>

We can see we have multiple tabs, and for kicks I nested the datepicker component from the previous CDK entry.

So here it is, the jQuery UI tabs plugin wrapped with the RichFaces CDK, providing us with a bare-bones tab component. A lot more work is required to get this to a point where it could replace the RichFaces tab component, but we have succeeded in creating a functional component leveraging existing javascript code, and without a lot of work on our part.

RichFaces 4.1.0.CR1 Release Announcement

I’m excited to announce the availability of RichFaces 4.1.0.CR1, the first release candidate for RichFaces 4.1.0. Stability of the platform has been a strong focus for all the RichFaces 4.1.0 milestone releases, and has been even more so of a focus for our CR1 release.

We really appreciate the community feedback we’ve received throughout the 4.1 development cycle, with each of the milestone releases. The bugs found and the suggestions provided from the community have really helped us nail down this release. As such, we are encouraging everyone to download this release candidate, and help us flush out any regressions or other potential blocker issues. Let us not forget, "given enough eyeballs, all bugs are shallow"!

To try out this release, you can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.1.0.20111111-CR1. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

With that “call to arms” out of the way, let’s take a look at what’s changed in this release.

Mobile Compatibility
We have been working on the RichFaces mobile guide, and will have it available shortly - watch for it the RichFaces wiki. Refer to this guide to take advantage of the mobile compatibility of the RichFaces components in our mobile showcase as we presented at a recent JBoss webinar (video of the webinar is available). The CSS and javascript we used in our mobile showcase has been cleaned-up and refactored, and ready for public consumption, with details of how to do so in the mobile guide.

We've also improved the mobile compatibility of some individual components, such as the calendar component (specifically the time picker), and the rendering of the pickList buttons. Thanks to the community members who pointed these deficiencies out!

Documentation
The Component Reference and Developer Guide have been updated for this release candidate, in preparation for the upcoming final release. In addition, a bug in the automatic generation of the VDL-DOC (tag library docs) has been addressed, once again providing a complete listing of all RichFaces components’ attributes. The latest javadoc has also been published.

Many of the attribute descriptions themselves in the VDL-DOC still need to be filled out (pull requests here would be very welcome!) - so be sure to refer to the Component Reference to supplement the VDL-DOC.

Framework upgrades
We upgraded our client-side bean validation extension to use Hibernate Validator 4.2, aligning with what is currently shipped in JBoss AS 7, and with what developers will be using with their applications. We also changed the project compiler compatibility to Java SE 6.0, reflecting in reality what has been true for the project for some time. We also started verification of the RichFaces platform against the upcoming JBoss AS 7.1 release, aiming for a smooth transition for RichFaces applications when AS 7.1 is released.

Individual improvements
Individual components have seen some improvements with this release. Ajax rendering of drag sources and drop targets has been improved, tab panel switching across the client/server has been cleaned up, and the tooltip was changed to better respect the value attribute for delivering the tooltip message. In addtion to these individual fixes, we addressed a number of IE8 compatibility issues.

Onward to Final
Unfortunately, we’ve have introduced some regressions with this release, namely with the calendar component and table sorting/filtering. These issues have already been addressed in our development branch, and will be ready for the upcoming final release.

Be sure to give this release a spin, and help us make 4.1.0.Final a top-notch release!

RichFaces 4.1.0.M4 Release Announcement

The RichFaces 4.1 Milestone 4 release is now available for download! With this M4 release we focused on stabilizing the features we introduced in the earlier 4.1 release-train milestones (M1, M2, M3). The release following M4 will be our 4.1 release candidate, so we want to make sure we achieve maximum stability with M4. Some of the key areas we touched are listed below.

If your keen and want to get started right away, you can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.1.0.20111101-M4. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Mobile showcase improvements
The CSS 3 overlay was improved to provide better mobile compatibility of the components. We also added an ajax status indicator to the mobile showcase. Since it is entirely an ajax driven application, the status indicator improves the user experience dramatically.

Resource mapping
The resource mapping feature introduced in M3 has been made more usable, adopting a consistent naming convention, with reasonable defaults. Additionally the ability to completely disable the feature was introduced, should you want to handle resources yourself in your applications.

Client Side validation
Improvements to the client-side validation (CSV) involved better aligning the client-side regexp with the Bean Validation specification. The CSV mechanism for discerning component values on the client (using javascript) was enhanced to improve the CSV interop with other JSF component providers.

Individual component fixes
The file upload component has some new attributes, allowing for more fine-grained control over what the user is able to upload to the server. The pickList saw the switchByClick and switchByDblClick functionality from RichFaces 3 ported to RichFaces 4, further improving the RF 3 to RF 4 migration story.

Misc. Fixes
Some additional issues resolved include a jQuery update (to version 1.6.4), and improvements to both the simpleapp and GAE RichFaces archetypes. Many more fixes and improvements were checked, feel free to browse the issues fixed to see what else has been improved.

Forward: CR1 & Further Stabilisation
The CR1 development is currently ongoing, with a focus on providing documentation for all the new 4.1 features, and further stabilisation. So give M4 a spin, and let us know what you think! Drop a note in the forums, or join us for our weekly community/team meetings in IRC.

RichFaces 4.1.0.M3 Release Announcement

The RichFaces 4.1 Milestone 3 release is now available for download. Further building on the new components and framework improvements introduced in the M1 and M2 releases, M3 brings it all together with an improved showcase - featuring a demonstration of the mobile compatibility of the RichFaces 4 component set. Along-side improvements to resource handling, and enhancements to the push component, we’ve fixed a number of bugs and issues, as voted by you - our user community!

Showcase - Going Mobile

The showcase as seen on mobile
devices (using device detection)

The showcase has received some attention in this release. First and foremost we’ve demonstrated the mobile compatibility of the existing component set with the addition of some simple css and javascript resources (using a well vetted approach).

The mobile showcase in RichFaces is a an initial mobile effort, focusing on making the existing RichFaces components work within mobile browsers. While not a full-blown set of mobile components, we’ve tweaked the framework as necessary and put forward the mobile showcase as an example of how you can make your existing RichFaces applications mobile-friendly with the current RichFaces component set. Stay tuned for an upcoming blog entry with details on how you can take advantage of this in your own applications. Or, if you’re feeling adventurous, have a look at the showcase code to see how we did it!

Showcase - On OpenShift
We've deployed the showcase application to OpenShift -- the PaaS offering by Red Hat. The OpenShift Java EE 6 support provides a great platform to take your application all the way from development with Express (free!) to production with Flex (highly scalable!). Express is a shared multi-tenant environment made to be as simple as possible to get started quickly, while Flex gives you dedicated VMs and DevOps control over architecture along with monitoring. For the RichFaces project, this gives us the chance to showcase our components in a Java EE environment, where our framework really shines!

(Note, until 4.1 is released, the showcase at http://richfaces.org/showcase will continue to demonstrate the RichFaces 4.0 framework and components).

Showcase - New Component Samples
Additionally we’ve added some polish to the showcase with bug fixes and user experience tweaks, and we've included samples of the latest RichFaces components. You will now find showcase samples for the rich editor, notify, orderingList, and pickList components, complete with samples showing you how to put them to good effect in your applications.

Resource handling
Along-side these showcase improvements, we’ve introduced framework improvements to improve the mobile experience. With the new RichFaces 4.1 Resource Handling features, we are packaging and minifying the out of box JavaScript and CSS. This is in an effort to reduce HTTP requests made by the framework and to give mobile apps (or any app) a boost in performance. For those familiar with RichFaces 3, this also brings back the old LOAD_ALL configuration, albeit with a new name. We’ll have a blog post out shortly, with details on how you can try these features out with the Milestone 3 release.

Ajax Push
Last (and by no means least!) I’d like to mention that the AJAX push component has seen a lot of improvements with this release. We’ve introduced a CDI interface for firing push events. This is not intended to supercede the existing Push API, but is instead provided as a means to tie the powerful CDI event mechanism into the RichFaces push technology.

Coupled with earlier push improvements (removing the JMS requirement from the push component), the push component is shaping up to be much more accessible to developers working in either Java EE or Servlet container environments.

Forward: M4 & Stabilization
Work is already well underway with our M4 release, where we are improving on the compatibility of our components with mobile browsers, and adding a last round of small feature improvements. Give M3 a spin, and let us know what you think! Drop us a note in the forums, or join us for our weekly community/team meetings in IRC.

RichFaces 4 CDK | jQuery UI Calendar

Further incrementing the complexity over the input component we created previously, this time we will create a JSF calendar component. Being pragmatic OSS developers, we will leverage the existing javascript of the datepicker component from the jQuery UI project, and we'll see how well the RichFaces CDK lends itself to mapping JSF component attributes into javascript configuration options.

As always, if you are interested in following along in your IDE, you can get the code below on github.

The Component Class
Starting again with the component class:

AbstractDatepicker.java

package ca.bleathem.richfaces.jquery.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.jquery.Datepicker",
        family = "ca.bleathem.Datepicker",
        renderer = @JsfRenderer(type = "ca.bleathem.jquery.DatepickerRenderer"),
        tag = @Tag(name="datepicker"))
abstract public class AbstractDatepicker extends javax.faces.component.UIInput {

    @Attribute
    public abstract String getDateFormat();

    @Attribute
    public abstract String getShowOn();

    @Attribute
    public abstract String getButtonImageOnly();

}

Here we see we are again extending the UIInput class, as we did with the Input component.  What's new is the introduction of some additional attributes.  The @Attribute annotation instructs the CDK that these abstract getter methods map to component attributes, and the CDK then takes care of wiring the attributes into the JSF state saving mechanism for us.

The naming convention of the attribute is alligned with jQeury UI datepicker options. This allows us to transparently pass the JSF component attributes through to the jQuery plugin, as we see in the Renderer below.

The Renderer
The renderer is again an xml file:

datepicker.template.xml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el" xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
    xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core" xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite"
    xmlns:javaee="http://java.sun.com/xml/ns/javaee">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.jquery.renderkit.DatepickerRenderer</cdk:class>
        <cdk:superclass>ca.bleathem.richfaces.jquery.renderkit.DatepickerRendererBase</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.jquery.DatepickerRenderer</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        <input type="text" id="#{clientId}" name="#{clientId}" class="rf_jq_cal" value="#{getInputValue(facesContext, component)}" />
        <script type="text/javascript">
            <cdk:scriptObject name="pluginOptions">
                <cdk:scriptOption name="buttonImage" value="#{getResourcePath(facesContext, 'ca.bleathem', 'calendar.gif')}" />
                <cdk:scriptOption attributes="showOn dateFormat buttonImageOnly" />
            </cdk:scriptObject>
            jQuery(function() {
                $(document.getElementById('#{clientId}')).datepicker(#{toScriptArgs(pluginOptions)});
            });
	    </script>
    </cc:implementation>

</cdk:root>

Diving first into the cc:implementation of this renderer template, we see again an input element. What's new is the script tag following the input. This script tag get's compiled into javascript when the component renders. Using CDK xml markup, we build up the javascript object pluginOptions which we pass as a parameter to the call to the jQueryUI plugin.

The document.getElementById('#{clientId}') is a workaround for JSF's use of the ":" character in javascript IDs - this doesn't play well with jQuery. By first calling document.getElementById, we end up with an argument that is acceptible to jQuery. Notice the #{toScriptArgs(pluginOptions)} argument to the datepicker jQuery UI plugin. This initializes the datepicker plugin, with the JSF component attributes specified by the application developer.

From the cc:interface of this renderer template, we see that we are extending the class DatepickerRendererBase. This class is included below:

DatepickerRendererBase.java

package ca.bleathem.richfaces.jquery.renderkit;

import org.richfaces.renderkit.InputRendererBase;

import javax.faces.application.ResourceDependencies;
import javax.faces.application.ResourceDependency;

@ResourceDependencies({
        @ResourceDependency(library = "javax.faces", name = "jsf.js"),
        @ResourceDependency(name = "jquery.js"),
        @ResourceDependency(library = "com.jqueryui/css/ui-lightness", name = "jquery-ui-1.8.16.custom.css"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.core.js"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.widget.js"),
        @ResourceDependency(library = "com.jqueryui/development-bundle/ui", name = "jquery.ui.datepicker.js"),
        @ResourceDependency(library = "ca.bleathem", name = "calendar.gif")
})
public class DatepickerRendererBase extends InputRendererBase {
}

The DatepickerRendererBase class is again extending the InputRendererBase, and it is holding a number of @ResourceDependency annotations. These annotations ensure the appropriate resources are included on the page when we reference this JSF component. For us, these resources are the jQuery UI plugins necessary to get the datepicker component working.

Introducing an entire new class merely to hold the @ResourceDependency annotations may seem like overkill, but in any reasonably complex component, we will end up putting some renderer helper logic into this class file. There are times when the expressivity of Java works better than the declarativity of xml. We'll see some of this later in our blog series.

Finally, let's look at en example use of this component:

sample.xhtml

<!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:ui="http://java.sun.com/jsf/facelets"
      xmlns:b="http://bleathem.ca/test"
      >

<body>
<ui:composition template="/templates/template-jqueryui.xhtml">

    <ui:define name="title">Datepicker Sample</ui:define>

    <ui:define name="body">
        <h:form>
            <b:datepicker value="#{myBean.value}" dateFormat="yy-mm-dd" showOn="both" buttonImageOnly="true" /> <br />
            Input value: <h:outputText value="#{myBean.value}" /> <br />
            <h:commandButton value="Submit" action="null"/>
        </h:form>
    </ui:define>
</ui:composition>
</body>
</html>

When rendered, this looks like:

Screen shot

While this has certainly grown in complexity over our initial HelloWorld component, we've managed to keep our JSF component development DRY. We've leveraged existing, high-quality javascript components. We've also made use of the RichFaces CDK to wire the JSF configured component to the javascript object. Some additional work is required to continue mapping the jQuery UI datepicker plugin options into JSF component attributes, but the mechanism for this has been laid out, and completing the component will be quite straight forward (pull requests welcome!).

In my next CDK installment, we'll look at creating a layout based component, rather than an input component. Stay tuned!

Testing AS7 web apps over SSL

Here's a recipe I found useful for trouble-shooting a web-app over an SSL connection. The steps involved are to:

1. Set the server name/IP on each of the testing machines (both Windows and Linux)
2. Create a self-signed certificate for the server using the java-based keytool
3. Export the certificate for installation as a CA in the clients
4. Configure JBoss AS7 to use the certificate sotre

All the above steps are sufficiently simple, but each required it's own share of googling to get everything just right. This post is as much a set of notes to myself in the future, as it is a blog.

1. Setting the Server name

On your Linux testing machine, make sure the sure IP and name of your local server are in your /etc/hosts file:

127.0.1.1 bleathem-redhat bleathem-redhat.local

Do the same thing for you windows clients - that's right! Windows has a /etc/hosts file! See this wikipedia article to locate the file in your version of windows.


2. Create a self-signed certificate
Use the java keytool command to create the certificate store:

keytool -genkey -alias tomcat -keyalg RSA -validity 3650 -keystore server.jks

when asked for your "first and last name", answer with the fully-qualified domain name. For me this is bleathem-redhat.local.

3. Export the certificate
Export the certificate from the keystore you just created, again using the keytool command:

keytool -exportcert -alias tomcat -keystore server.jks -file as7.cer

Copy this certificate to your Windows clients, and install it as a certificate authority. I found this to be necessary, as IE9 is particularly nasty about dealing with "unofficial" certificates. Steps to do this are left as an exercise for the reader! (I don't feel like taking a bunch of windows screenshots.)


4. Configure JBoss AS7
In the standalone.xml configuration file of your AS7 instance, find the line:

<connector name="http" protocol="HTTP/1.1" socket-binding="http" scheme="http"/>

And add below it the lines:

<connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" secure="true">
    <ssl name="https" password="changeit" certificate-key-file="standalone/configuration/server.jks"/>
</connector>

This will configure your AS 7 instance to use your newly created certificate store on it's SSL enabled port. The default https port for AS7 is 8443.

And there we have it!  A fully functional SSL/https enabled environment for testing our web apps!

RichFaces 4 CDK | Input Component

With our last component, we saw how we could output some simple text with a custom JSF component created with the RichFaces CDK. Let's increment the complexity, and see how we can create a component that accepts input. Again, the goal here is to highlight how the important features fit together, and to leverage as much of the plumbing work as possible from the RichFaces CDK.

If you are interested in following along in your IDE, you can get the code below on github.

The Component Class

In a similar approach to our Hello World component, we'll start with the component class for our Input component:

AbstractInput.java

package ca.bleathem.richfaces.input.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.input.Input",
        family = "ca.bleathem.input",
        renderer = @JsfRenderer(type = "ca.bleathem.input"),
        tag = @Tag(name="input"))
abstract public class AbstractInput extends javax.faces.component.UIInput {

}

This looks pretty similar to the component class for the Hello World component, with an appropriate changing or type, family, renderer and tag. One significant change to take note of is the base class for the component. Notice how we are extending the UIInput class. This allows us to leverage the value holding and state saving that has already been built into this component. No matter what kind of UI you want to build for your component, you will almost always want to store a single value (we'll discuss select many components in another post). So extending UIInput is generally a good idea.

The Renderer

The corresponding renderer template for our input component is:

input.template.xml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el" xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
    xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core" xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite"
    xmlns:javaee="http://java.sun.com/xml/ns/javaee">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.input.renderkit.InputRenderer</cdk:class>
        <cdk:superclass>org.richfaces.renderkit.InputRendererBase</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.input</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        <input type="text" name="#{clientId}" value="#{getInputValue(facesContext, component)}" />
    </cc:implementation>

</cdk:root>

Again, this looks pretty similar to the template for the Hello World component. The key difference being the Renderer superclass, and the html markup in the cc:implementation. By extending the RichFaces InputRendererBase class, we save ourselves from having to write the logic to decode and invoke the validators for our component. Again, this is something we will want to do for many of the components we write.

The html markup is also rather simple. By giving the input element the name of our component ID, we are indicating which form component should be decoded when the component is processed. When authoring a component with a complex UI, you will often make this input element a hidden input type, to store and submit your value while not interfering with your UI. We'll see more of this in later entries of this CDK series.

I'll also add that the package-info.java file described in the Hello World entry is still required, if you don't already have one included in your jar.

And that's our input component - again done as simply as possible. The next entry will wrap an existing jQuery UI component, showing how the CDK is an effective means to leverage the work others have already put in to authoring complex javascript components.

RichFaces 4.1.0.M2 Release Announcement

The Richfaces 4.1 milestone releases are trucking along. With M1, we had a focus on changes surrounding project infrastructure, and the introduction of some new components. Now with M2 we see updates to the core, and a stabilization of both the new components and the framework as a whole.

jQuery Upgrade

We built the RichFaces 4 components using jQuery for DOM manipulation. Given the degree to which the we rely on jQuery, upgrading it is a "big deal". In order to ensure none of our components break during this milestone release, both our QE and Dev teams have been busy tending to our test infrastructure. The benefit of shipping with the latest jQuery is that it provides better compatibility to application developers wishing to leverage cutting edge jQuery plugins, or integrate with other component libraries.

IE9 support
As part of our extensive testing of our platform, we noticed a number of compatibility issues with Internet Explorer 9 running in strict or normal mode. We isolated this as an upstream issue, and will work with the Mojarra team to patch the underlying problem. In the mean-time, the issues can be worked-around if you run IE 9 in compatibility mode.

Stabilization of the new components
The new components introduced in M1 have benefited from further development, and constructive user feedback (thanks!).

rich:editor
The Editor has several new features, but the most valuable is the integration with the standard RichFaces styling scheme. Further details are available in Lukas’ blog post.

rich:notify
Notify Messages have been better integrated into the RichFaces ecosystem, allowing them to consume Client-Side Validation messages. The Notify Stack was also refactored - this is where one configures the location and orientation of messages.

rich:pickList
The Pick List has picked up ordering capabilities in the target list, making it now a viable replacement for the older listShuttle from RichFaces 3. In addition, the Pick and Ordering Lists have exposed more events, allowing for applications to better hook into their behavior.

Face-to-Face
A fair chunk of time during the M2 sprint was spent by the team in a face-2-face meeting, where our world-wide development team came together to discuss the future of the project. Stay tuned for updates along these lines, as we distill our ideas and engage the community for feedback to collectively define our project vision and future.

Forward: M3 and mobile
As always, we've taken care of a number of bug fixes with the M2 milestone release. However, the upcoming M3 release is when we will buckle down and focus on taking care of stabilizing the platform as a whole, and fixing as many bugs as we can, particularly in the mobile space. To help us better identify where we would best be spending out attention, please get on Jira, and vote for the issues that are important to you.

RichFaces 4 CDK | Hello World

This is the first technical post of my CDK series. Starting real simple, we'll create a component that produces a hello world output. "Why start with a hello world? Isn't that a little cliche?". Well indeed it is, but it is by far the best way to point out the fundamental pieces of the CDK, and how they together. We'll build a strong foundation in our understanding of the CDK, on which we can build more interesting components in future posts.

If you are interested in following along in your IDE, you can get the code below on github.

The Component Class
To start, we need a component class. The component class itself will be generated by theRichFaces CDK. However we do define a base class from which the generated class will extend. We'll see why this is the case when we get to more complex components. But for now, let's start with this base class:

AbstractHello.java

package ca.bleathem.richfaces.hello.component;

import org.richfaces.cdk.annotations.*;

@JsfComponent(
        type = "ca.bleathem.richfaces.hello.Hello", 
        family = "ca.bleathem.text", 
        renderer = @JsfRenderer(type = "ca.bleathem.hello"), 
        tag = @Tag(name="hello"))
abstract public class AbstractHello extends javax.faces.component.UIComponentBase {

}

Here we have an abstract class annotated with @JsfComponent. This annotation marks the class as a CDK class, and will be consumed by the CDK pre-processor. The CDK uses the attributes of the annotation to construct the necessary classes, and the necessary xml configuration. Creating JSF components is verbose, but we don't have to worry about the verbosity - the CDK takes care of it for us!

Let's look more closely at the @JsfComponent annotation, and the meaning of each of it's attributes. I'll start by pointing out that the annotation supports many more attributes, but we are only covering here the bare minimum required to get a simple hello world component created.

type

the value of the type attribute is how JSF identifies out component. It will be used in the generated faces-config file, and in the generated xml taglib file.

family

the value of the family attribute is used by JSF to recognize "like" components. We'll get into details of this in future posts. This attribute is in fact optional, and the value can be generated by naming conventions. However, I prefer to specify it explicitly.

renderer

the value of the renderer attribute is used to match our component to an appropriate renderer. We'll create the renderer next!

tag

the value of the tag attribute will be the actual facelet tag that we use in our facelet files.

The last aspect of out component class that I want to point out is the "extends UIComponentBase" part. Every JSF UI component must extend this class, or one of it's descendants. We'll be able to save ourselves alot of work when we get to more complex components, by judiciously choosing the right class to extend.

The Renderer

Next, let's look at the JSF Renderer:

hello.template.xml

<?xml version="1.0" encoding="UTF-8"?>

<cdk:root xmlns="http://jboss.org/schema/richfaces/cdk/xhtml-el" xmlns:cdk="http://jboss.org/schema/richfaces/cdk/core"
    xmlns:c="http://jboss.org/schema/richfaces/cdk/jstl/core" xmlns:cc="http://jboss.org/schema/richfaces/cdk/jsf/composite"
    xmlns:javaee="http://java.sun.com/xml/ns/javaee">

    <cc:interface>
        <cdk:class>ca.bleathem.richfaces.hello.renderkit.HelloRenderer</cdk:class>
        <cdk:superclass>javax.faces.render.Renderer</cdk:superclass>
        <cdk:renderer-type>ca.bleathem.hello</cdk:renderer-type>
    </cc:interface>

    <cc:implementation>
        Hello World! (from a RichFaces CDK component)
    </cc:implementation>

</cdk:root>

If you are familiar with JSF Component development, you may be surprised to see that our Renderer is not a java class. On the other hand, you may find that it looks quite similar to a JSF 2 composite component. It has a "<cc:interface>" section, and "<cc:implementation>" section, both of which are analogous to the facelet file of a composite component. In fact, you can prototype your components as composite components, then migrate to CDK components when you find you need the extra flexibility the CDK provides.

As we did for the component class, let's dissect the cdk tags found in our renderer template.

<cdk:class>

this is the name of the JSF Renderer class that will generated.

<cdk:superclass>

the class that will be extended by our generated JSF Renderer class. Here we are explicitly stating the default for reference when we get into more complex components.

<cdk:renderer-type>

this is how JSF identifies our Renderer. It will be used in the generated faces-config file, and in the generated xml taglib file.

And there we have it, a JSF Component, and it's associated Renderer! -- err almost. There is one final piece missing. We need to specify a name space for our component - the namespace that will be used on facelet pages that refer to our components. Fortunately, the CDK also makes this easy for us. All we need is a package-info.java in the java package of our component:

package-info.java

@TagLibrary(uri="http://bleathem.ca/test",shortName="testLib")
package ca.bleathem.richfaces.hello.component;
import org.richfaces.cdk.annotations.TagLibrary;

Here you can see the @TagLibrary annotation that specifies the namespace of our component.

Now we can build a jar, include it in our application, and use our hello world component! Go ahead and run the build. If you are curious, take a look in the target/generated-sources folder. There you'll see all the JSF classes and xml files that the CDK generated for us. Those are all classes and xml files we would have had to write ourselves if we weren't using the CDK.

Well, a hello world JSF component - not really useful... but there is more coming! The next entry in this series will use the CDK to create an input component, and from there we'll get into some more sophisticated components!

In closing, I want to add that the CDK is incredibly flexible, and there all multiple ways the above component could have been put together. I'm sticking to what I think is simplest, most clear, and most extensible.

Seam Faces Community Hack Night

Seam Faces Community Hack Night!

This week's Seam 3 Community hack night is centered around Seam Faces.  This is a great chance to mingle with some CDI/JSF developers on IRC, and get your fingerprint into the Seam Faces DNA!  Whether you have your own itch you want to scratch, a long-standing bug you want to see resolved, or implement a new feature altogether, we've got plenty of low hanging fruit ripe for the picking!

In preparation for the hack-a-thon, I've given the Seam Faces JIRA issues a once-over.  I've collected a number of issues that I feel are ready to be resolved into a JIRA version calles 3.1.0-Tracking.  I'd like to highlight a few of the issues here, and perhaps motivate you to come join us at the hack-a-thon to resolve some of them!

SEAMFACES-122: Type safe navigation!
Of all the low-hanging fruit, this one has to be the juiciest!  Implement a Navigator utility class to map the @ViewConfig enums to their String @ViewPattern's for use in JSF navigation.  Imagine using your IDE to find all usages of one of your views - type safety FTW!

SEAMFACES-26: Implement global protection against XSRF attacks
Help the community of Seam 3 developers make their apps more secure by implementing a scheme to protect against XSRF attacks!  Think hidden form field, view state and a random number generator.

SEAMFACES-28: ObjectConverter and EntityConverter
Let's resurrect the Entity Converter from Seam 2.  The EntityConverter is persistent context aware, and will use the primary key of your JPA/Hibernate entities to handle JSF Conversion.

SEAMFACES-150: Refactor BeanManagerUtils to make use of Solder's BeanManagerLocator
Are you aware with the Seam Solder API?  Want to learn more about how to wield this powerful tool?  Here's a refactoring that will surely get you more comfortable with how to use Solder.

SEAMFACES-6: s:debug
This issue is very well documented in JIRA, and just needs someone to put the pieces together.  What a great tool to add to your arsenal once complete!

SEAMFACES-185: Add support for activating beans based on the JSF project stage
Christian Kaltepoth has done a great job with this issue, but we've got a tough nut to crack.  How to parse the web.xml before the Servlet Context is available?  If you got some ideas here, help us bring this one across the finish line.

SEAMFACES-184: Extend an example to demonstrate events propagation features
Familiar with Seam Faces, but don't feel up to hacking on the core?  How about writing an example application, to demonstrate some of Seam Faces' cool features?

SEAMFACES-152: Create documentation for using Seam Catch in Faces
Another great way to contribute to the project, without writing a single line of code is to contribute docs!  Help other Seam 3 devs figure out what you already know!

These are just a few of the issues ready to be solved during the hack night.  So drop by on IRC, and give us a hand squashing some issues.  At the very least, I'm sure you'll have fun!

RichFaces 4 CDK | Introduction

A new blog series

Having recently dived head first into the RichFaces 4 Component development Kit (CDK), I thought it would be useful to share the knowledge and experience I've gained.  Over the next few weeks, I am going to put out a series of blog posts giving some examples of how to use the RichFaces CDK.  Hopefully by the end of this series, we will have written some interesting components and left you with the urge to write your own JSF components using the CDK!

Before I get into specific examples, I’d first like to motivate the series by describing what exactly the CDK is and the problems that it solves.  If you already know all about JSF components, and you want to get straight into using the CDK, skip this blog post! - the rest of the entries in this series will deal purely with implementation details.

What is the RichFaces CDK anyway?

JSF was designed to make components easy to consume.  The syntax is very html-like, and EL makes it easy to bind components to backing beans.  However, writing JSF components has traditionally not been very accessible.  With the number of classes that one has to create and wire together, along with a requirement for detailed knowledge of the JSF API, components were typically left to third party component suites, like RichFaces, IceFaces and Apache. Things were improved drastically with the release of JSF 2.0, and it’s support for composite components.

Composite components let the user build JSF components purely in xhtml - without requiring any lines of Java.  This is a fantastic improvement, as developers can build their own re-usable components that encapsulate a fair amount of complexity and keep their applications DRY. An overall bonus indeed! While composite components achieve a lot, the mechanism falls short when it comes to creating full-fledged JSF components.

The concise and non-java nature of composite components that makes them so appealing, is also their biggest limitation.  Oftentimes one needs additional expressivity not available in EL, or one needs to tap further in to the JSF lifecycle.  Thus in JSF 2, the component suite providers find themselves once again writing components in Java, to be able to take advantage of the rich APIs that JSF provides.
This is where the RichFaces CDK comes in.  The RichFaces team provides the CDK as a means for developers to write JSF components with many of the simplifying advantages of the JSF 2 composite components, but also with the full power and flexibility provided by the JSF component APIs.


JSF Components simplified with the CDK

To understand how to use the CDK, one first has to understand how JSF components are put together.  At the end of the day, JSF components are built out of Java classes, and the CDK is simply an effective means to generate those classes.

To build a JSF component, one starts by extending the UIComponent class.  This class defines the attributes and API of your component and is responsible for hooking into the JSF state saving mechanism.  While you could put your rendering code into this component class itself, you’re better off putting that rendering code in a separate Renderer class.  You’ll also end up writing a TagHandler class to couple the Render and component.  And should your component fire FacesEvents, well you’ll need to implement additional interfaces and provide more classes.  Lastly you’ll need to register these classes in the faces-config.xml and provide a taglib.xml file.  Now there’s a mouthful!

The CDK simplifies this all for us, by generating a lot of the above code.  All we need to create when we use the CDK is a component base class, and an xhtml file to define the rendering behaviour called the “Renderer template” .  This Renderer template is designed to build on the JSF 2 composite component mechanism, so if you can build JSF 2 composite components, you’re already half-way there!

With the component base class, the Renderer template, and the annotations that couple them, the CDK is able to generate the rest of the required files for us.  There is nothing sub-standard about these generated classes - they are full-fledged JSF components in every way!  In fact, much of the RichFaces 4 component suite is built using the CDK!

There is a lot of detail to cover in how to write the component base class, and the accompanying Renderer template.  I’ll begin covering these details in my next post, where we will write a “Hello world” JSF component using the CDK.  But if you can’t wait for my post, feel free to dive into the RichFaces CDK docs.

RichFaces 4.1.0.M1 Release Announcement

The RichFaces team is proud to announce the first milestone release of RichFaces 4.1. This release includes some significant contributions from community members, adding to and building on top of the efforts of the RichFaces core developer team! You can find this development release on the project’s download page and check out our “getting started” resources.

First Milestone for 4.1

The 4.1.0 Milestone1 release includes several highly anticipated features and improvements in RichFaces 4.

We have new components:

• Editor
• Pick List
• Ordering List
• Notify

In addition, we’ve made some big improvements to the Push component.  It is now more lightweight, decoupled from JMS, and support has been added for Comet - the websockets-like light alternative for long-poliing.  A Push demo has also been added to the RichFaces Showcase, with support for JBoss AS 7 (although not yet visible in the public showcase, the code is available).

In addition, a new sample application Tweetstream has been developed.  This application demonstrates the “mobile platform” directions and capabilities that can be expected from future releases of RichFaces.

New Components

Three of the new components, “Editor”, “Pick List”, and “Ordering List” are components that were available in RichFaces 3, but were not present in the initial RichFaces 4 release.  With this first milestone release for RichFaces 4.1, we have remedied this and provided these missing components.  The 4th new component, “Notify”, is a community contributed component, the first component contributed from Bernard Labno - a RichFaces community enthusiast.  Let’s take a closer look at each of these components:

The Editor component has been rewritten from scratch, and is now based on the CKEditor implementation. It traditionally supports two modes of toolbar button configuration (basic and full) and nicely integrates to rest of the RichFaces AJAX  framework. In the milestone 2 release, it will also get a new Look & Feel to be better aligned with the rest of the component suite.  For further details, see Lukas’ blog post on the rich editor.


The Pick List and Ordering List are two other components that were sorely missed by the community since RichFaces 3, and they have now been re-introduced.  The new Pick List in RichFaces 4 incorporates the functionality of both the List Shuttle and Pick List components from RichFaces 3. The API of this Pick List component has been specifically redesigned to follow the f:selectItems pattern and to allow a quick transition from the h:selectMany component.


Lastly, the Notify component provides interactive feedback from your applications complementary to standard messages.  The look and behaviour of the Notify component was Inspired by Mac OS’s growl to provide your JSF applications with a more rich user experience

The components provided in this first milestone are functionally complete, so you can take them for a spin, and provide us with your feedback about any functionality or key API’s we might have missed (or where we got it right!)

Migration to Git

New features and functionality have not been our sole focus. In preparation for this release we’ve migrated our entire framework to GitHub and broken it up into several modules.  The main goal we had in mind with this migration was to make contributing to the RichFaces framework easier, and help us extend the level of collaboration.  I think we can say we’ve definitely achieved this goal, given the number of community contributions we’ve already seen.

With GitHub, it is now pretty easy to send patches to the project in form of pull requests. Thanks to git-flow it is now trivial process to develop new features in feature branches and, because of Git itself, it is easy to merge them back into the most recent development branch.

Next Milestone

Milestone 2 will be a great sprint for ironing out the details of the new components’ features as well as polish their look&feel.  Most importantly however, we will focus on further stabilization of the framework by fixing bugs both reported by the community and those found by our QE team. A lot of work is also planned for mobile devices support, and as previously mentioned, we are working on initial versions of a Mobile Showcase.

Face to Face Meeting

After Milestone2, the globally distributed RichFaces team will get together with some other JBoss teams in Toronto, Canada,  to discuss the future of the framework itself and it’s integration with other parts of Java EE.  The goal of this meeting is to offer you, the developer, the best development experience possible. Should you be around Toronto in September and would like to join us for an evening beer, you are more than welcome. ;-)

Give it a spin!

Go ahead, and download this first Milestone release of RichFaces 4.1 (or add the dependency to your maven pom file), and give the new components a spin.  Let us know what you think, either where we’ve missed something, or where we got it right, and help shape the component for the upcoming 4.1.0.Final release.