Practical RichFaces, Second Edition

CHAPTER 1 THE BASICS
Validation. It is now possible to perform validation on the client according to JSR-303 definitions. It
means that basic client-side validation no longer requires creating and plugging custom JavaScript
validators to components; it just synchronizes them for different layers at the framework level.
Also, with RichFaces you will be able to achieve that validation across the whole application
following the DRY (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principle. In case validating
on the client is not possible, Ajax fallback (server-side) support is available. Besides, RichFaces provides
so-called Object Validation that allows validating server-side Entities in the whole, even if some
properties are not present in current view. Client-side validation is covered in Chapter 11.
RichFaces’ Component Development Kit
Another part of the framework is the Component Development Kit (CDK). The CDK includes various
Maven archetypes, a code generation facility, descriptors and tests generation facility, and a templating
facility that allows the creation of renderer classes using only page code. These features enable a
component developer to avoid the routine process of component creation. The CDK greatly simplifies
and speeds up rich component development with built-in Ajax support. This edition of the book now
includes CDK coverage. CDK is covered in Chapter 13.
Using RichFaces with CDI and Dependency Injection
Contexts and Dependency Injection, or CDI (JSR 299), and Dependency Injection for Java (JSR 330) are
both part of the Java EE 6 platform. Both provide services and components to make it simpler to develop
enterprise Java applications. Although JSF 2 now provides a simpler way to configure beans with
annotations, using CDI beans instead of JSF beans gives a lot more flexibility and power to the developer
by providing a unified programming model. JSF 2 works with CDI Beans out of the box. As RichFaces 4 is
based on JSF 2, CDI can be used with any RichFaces 4 components as well. So that we don’t introduce
another layer (which is really outside the scope of this book), examples in this book will use standard JSF
beans. In all examples, JSF beans can be easily replaced with CDI beans.
RichFaces: A Historical Perspective
If you search for RichFaces, eventually you will see a reference to Ajax4jsf. This section provides a brief
history of Ajax4jsf and how it became part of RichFaces. Ajax4jsf has its roots in RichFaces. The Ajax4jsf
framework was created and designed by Alexander Smirnov. In early 2005, he was looking to add a
“hot” new technology along with the associated experience to his résumé. Roughly at the same time,
Jesse James Garrett was establishing the concept of Ajax. Meanwhile, JSF was starting to pick up steam.
Alexander figured, why not just merge the two so it would be easy to have Ajax functionality within a
JSF application?
He started the project on SourceForge.net, called it Telamon (taken from the Shakespearean play,
Antony and Cleopatra), and Ajax4jsf was born. In the fall of that same year, Smirnov joined Exadel, a
software engineering company, and continued to develop the framework. Smirnov’s goal was to create a
tool that was easy to use, would add client-side richness to pure server-side JSF technology, and could be
used with any existing JSF component libraries.
The first version of what would become Ajax4jsf was released in March 2006. It wasn’t quite a standalone
thing yet. Rather, it was part of a product called Exadel RichFaces. Later in the same year,
RichFaces was split off, and the Ajax4jsf framework was born.
While RichFaces provided out-of-the-box components, or what’s called a component-centric Ajax
approach (components that do everything you need), Ajax4jsf provided what’s called page-wide Ajax
support. You as a developer specify what parts of the page should be processed on the server after clientside
user actions, and also what parts should be rendered back (rendering is happening on the server