Wednesday, August 31, 2011

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.

Tuesday, August 16, 2011

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.

Seam Faces 3.0.2.Final released


(cross posted from :http://community.jboss.org/people/bleathem/blog/2011/06/20/seam-faces-302final-released)

Great news, Seam Faces 3.0.2.Final has been released! It is available for download via the JBoss Nexus repository. Primarily a bug fix release, Seam Faces 3.0.2.Final resolves some compatibility issues with MyFaces, thanks to contributions from Christian Kaltepoth. Additionally, José Freitas has contributed some fixes to issues with the UIInputContainer. A full list of the bugs fixed is available here.

I'm very excited about the community involvement in this release, and with more community members coming forward with features they'd like to see implemented/improved. If you have you're own itches you'd like to scratch, feel free to comment in the forums, file an issue in JIRA, or drop in on IRC. Then it's stratight to the source to fork the project on github! You're pull requests are very much appreciated!

Cheers,
Brian Leathem