JSF Central - A RichFaces Roundup - What's New With 4.2
JSF Central

 Articles & Books 
A RichFaces Roundup - What's New With 4.2
A RichFaces Roundup - What's New With 4.2
by Brian Leathem
15 Mar 2012 3:00 EDT

Brian Leathem discusses the latest developments in the RichFaces project. New components, mobile compatibility, resource loading optimizations, Ajax push, and CDI integration are all areas that have seen improvement with the recent 4.1 and 4.2 releases.

RichFaces is more than just a JSF component set for building your applications. RichFaces (along with the Seam project) has always aimed to provide developers with a complete JSF framework for developing applications. With the recent RichFaces 4.1 release, the project continues to build on the ideas of innovation, open standards, community and quality that have made the project stand out over the years.

Many of the RichFaces 3 features played a strong role in influencing the JSF 2 standard, particularly in the area of integrating Ajax within JSF applications, demonstrating Red Hat's commitment to contributing innovations back into open standards. However, to properly integrate with these standardized Ajax and resource handling capabilities, much of the RichFaces framework had to be re-written. This effort culminated with the release of RichFaces 4, providing both JSF 2 based components and a significant feature set, and once again providing JSF developers with a full-featured application development framework. Among these features, we saw the introduction of client-side-validation -- bringing the Bean validation to the browser, and enhancements to the JSF Ajax sub-system with enhanced queuing capabilities.

The RichFaces community is also very active in both our user/developer forums and in IRC, where we plan and implement the project in the open, welcoming community input and contributions. We also have a significant commitment to quality, with tens of thousands of functional and unit tests identifying problem spots and guarding against regressions as the project moves forward.

RichFaces 4.1/4.2

The 4.1 and 4.2 releases of RichFaces are significant, building on top of the successful 4.0 release by providing:

  • additional components migrated from the RichFaces 3 component set: editor (shown in figure 1), pickList, orderingList, contextMenu, and hotKey.
  • new community contributed components (the notify components)
  • significant enhancements to the framework feature set involving mobile compatible components, resource packaging, and push improvements.

  Figure 1 The RichFaces editor introduced in RichFaces 4.1, based on the popular CKEditor JavaScript library
Figure 1 The RichFaces editor introduced in RichFaces 4.1, based on the popular CKEditor JavaScript library

Mobile Applications

Beginning with RichFaces 4.1, you can use the RichFaces component set to create mobile web applications. The debate of native vs. web for mobile applications is well covered these days, and the real answer to such a question is highly use-case dependent. However, if your use case permits and you are keen to leverage your investment in both JSF/RichFaces skills and technology, then using JSF with RichFaces is a viable option for your mobile solution. For an example of the mobile-enabled RichFaces components in action, visit the RichFaces showcase on your mobile phone, as seen in Figure 2.

  Figure 2 The RichFaces showcase as seen on a mobile device
Figure 2 The RichFaces showcase as seen on a mobile device

All that's required to enable the mobile compatibility of the RichFaces JSF components is to include and activate the mobile-compatibility JavaScript and CSS files, as in this code example: <link rel="stylesheet" href="https://raw.github.com/richfaces/components/develop/mobile-compatibility/slidfast.css" /> <script type="text/javascript" src="https://raw.github.com/richfaces/components/develop/mobile-compatibility/slidfast.js"></script> <script type="text/javascript"> slidfast({ defaultPageID:'home-page', defaultPageHash: 'home', backButtonID: 'back-button' }); </script>

*Note: be sure to copy these files into your WAR and reference them locally -- github is not an effective CDN!

The JavaScript and CSS resources included are responsible for making the components compatible with a mobile environment, with touch areas increased to a sufficiently large size, and other usability improvements. These resources also enable us to effectively write applications with a "single-page" programming model by leveraging CSS 3 to invoke the device GPU for complex animations, such as page transitions.

The end result is that we can write effective and performant mobile applications with the tools and components we already know. Read more details about how to optimize your RichFaces applications for the mobile environment in our Mobile Getting Started guide.

Resource Loading Optimizations

Each individual component in the framework is responsible for identifying the JavaScript and CSS resources it requires. As each component includes its relevant JavaScript and CSS resources on the page, the browser ends up executing a number of additional requests to fetch each resource. While the overhead of this extra traffic is most noticeable on a mobile device, especially when not on a wifi connection, it also affects desktop environments.

To overcome this limitation, we've introduced resource packaging and minification capabilities into RichFaces. This packaging and minification step is responsible for combining the numerous JavaScript and CSS files into a single file (for each resource type), and applying an automated minification process to the result. This means the browser now has two resource files to download, which are in turn cached, providing an even greater performance benefit to subsequent pages.

To enable this feature in your web application, it's simply a matter of including the appropriate context-param in your web.xml:

<context-param> <param-name>org.richfaces.resourceOptimization.enabled</param-name> <param-value>true</param-value>

There are a number of other configuration options exposed as context-params, to fine-tune the behavior to your application. Lukas Fryc has a great blog post introduction explaining how you can take advantage of the RichFaces resource loading optimization; additionally, complete documentation of the feature is available in the RichFaces developer guide.

Another resource loading optimization introduced with RichFaces 4.2 is the ability to map a JSF resource request to the actual resource delivered. By providing a simple mapping file, you can trivially introduce a patched version of jsf.js, or even bundle your own jQuery file with your application. We are hoping this capability will help deliver on the JSF 2 promise of better component library compatibility, by avoiding the resource collision that occurs when the various component sets bundle similar resources.

RichFaces Push

The push component isn't new with RichFaces 4.1/4.2, but we have provided a number of improvements to our push technology in this release. In case you haven't seen it before, the push component looks like:

<a4j:push id="pushJms" address="pushTopicsContext"> <a4j:ajax event="dataavailable" render="uuid"/> </a4j:push>

Here the address is our push "topic," used to isolate the communication of different push components with your application. The Ajax component nested within the push component is triggered when a push event is received, re-rendering parts of the page as required.

When not in a CDI environment, a push event is fired programmatically using the traditional API as follows:

TopicKey topicKey = new TopicKey(PUSH_TOPICS_CONTEXT_TOPIC); TopicsContext topicsContext = TopicsContext.lookup(); topicsContext.publish(topicKey, "message");

New with RichFaces 4.1, we've provided a CDI interface for firing push events. The above code can be re-written as :

@Inject @Push(topic = PUSH_CDI_TOPIC, subtopic = "#{pushBean.userIdentifier}") Event<String> pushEvent; pushEvent.fire(message);

In addition to the standardized event syntax, it also now trivial to create your own listeners for push events by using the CDI @Observes annotation.

One of the strengths of the RichFaces push component when it was first made available was it's integration with JMS, providing a robust queuing mechanism for push events. This was great if you were deploying to a Java EE container, but was in fact a hindrance for those deploying to servlet containers. With RichFaces 4.1, we've made the JMS integration of the push component optional, and have disabled JMS integration by default in RichFaces 4.2. This change enables developers working in a wider variety of environments to take advantage of the technology out of the box, yet those who still wish to take advantage of the JMS integration can do so by setting the context-param org.richfaces.push.jms.enabled to true.

RichFaces is pushing forward on the integration of JSF with other Java EE technologies, by bringing the programming model standardized with CDI in Java EE 6 into the push component, and by leveraging JMS message queuing where possible.

RichFaces CDK

I consider the RichFaces Component Development Kit (CDK) to be a hidden jewel within the framework. Much of the RichFaces component set is written using the CDK, so the CDK itself is well tested in a number of different scenarios. The CDK is used to create full fledged JSF components, abstracting away as much of the plumbing as possible. This allows component authors to focus on the task of coding components, rather than configuring them via XML.

The RichFaces 4 CDK itself is modeled as an extension of the JSF 2 composite component concept. Component renderers are created as xhtml files, with the familiar and tags. The CDK extensions are introduced through the "cdk" namespace, and are consumed by the CDK to transform the facelet template file into the Java classes needed to provide a full-fledged JSF component. Creating classes out of the template files means we are not limited by the composite component approach, but instead can take advantage of all the integration points built into the platform for component authors. This hello world renderer demonstrates the key aspects of the template file:

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

One immediately recognizable advantage of the CDK is the ability to fall back to pure Java code whenever necessary. The renderer class generated by the CDK extends another class of your choosing, so you can put whatever functionality you require into that base class and invoke it from the template with the <cdk:call> tag. This turns out to be incredibly useful, as there are oftentimes problems better solved with Java code than with xml markup. Yet the overall structure of the component is governed by the template file, with a very accessible syntax.

I could write endlessly on the virtues of the CDK, but I hope I've managed to capture your imagination, and perhaps inspire you to create your own JSF components with the CDK. If you are interested in doing so, be sure to check out my recent blog series for a CDK primer.

RichFaces Future

Moving the RichFaces project forward, we are very keen on preserving the principles of innovation, open standards, community, and quality that have made the project so successful. We will continue to migrate components and features from RichFaces 3 into Richfaces 4, leaning heavily on the community to help us identify those areas where RichFaces 3 was stronger.

We will also really flex the CDK muscle in upcoming releases, as we look to provide additional component sets, and improve the ease and efficiency of developing with the CDK. These efforts will focus on providing new components with a rapid turnaround as we leverage existing OSS JavaScript widget projects. Key to this effort will be contributing back upstream to these projects, so we don't become over-burdened with maintaining JavaScript libraries.

One possibility we'd like to explore with this component set is to provide components usable both within JSF, but also with other web frameworks and technologies. This would leave application developers free to choose the appropriate technology within different areas of their applications, yet still maintain a consistent look and feel as they leverage the same JavaScript components throughout.

More to Come

Be sure to keep an ear out for more RichFaces releases to come, as we continue to innovate, providing better tools and capabilities for JSF application developers. If this area interests you, be sure to get involved -- we are very much a community oriented project, developing our framework in the open.


RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2014 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.