Apache MyFaces consists of many subprojects. Each subproject has its own release cycle. Most projects are available for JSF 1.1 as well as JSF 1.2. We will look at each of the subprojects briefly in this section to get an idea of what can be done with MyFaces. Where applicable, a forward reference is provided to a chapter where the project is discussed in detail.
Note that there is much overlap in functionality between some of the subprojects, and in particular in the component sets. This is because some component sets were donated to the MyFaces project by different companies at different times. Each of these component sets has its weaknesses and strengths. That being said, choosing a component set to be used for your project may not be an easy task. The information presented in this chapter is not sufficient to make such a choice. So, it is best to read the chapters on each component set before choosing any of them.
The Apache MyFaces Core project is where it all started. It does not do much more than implement the JSF standard. There are currently three relevant versions of this standard:
JSF 1.1: This version of the standard fixes some bugs in the original 1.0 version. Both the 1.0 and the 1.1 versions were specified by the Java Specification Request (JSR) number JSR 127. The versions of MyFaces Core implementing this version of JSF are numbered 1.1.x.
JSF 1.2: This version of the JSF standard was specified by a separate JSR, with the number JSR 252. JSF 1.2 adds some important improvements over JSF 1.1. The MyFaces Core versions implementing JSF 1.2 are numbered 1.2.x.
JSF 2.0: This brand new version of JSF will be part of Java EE 6.0. JSF 2.0 is specified in JSR 314, which had its final release on July 1, 2009. The versions of MyFaces Core implementing JSF 2.0 are numbered 2.0.x. At the moment of writing this book, only an alpha release is available.
The Core project currently has branches for each of these JSF versions. The 1.1 and 1.2 versions are stable and are updated regularly. Work is in progress on the 2.0 version, but a stable release is not yet available, as of the time of writing this book. In this book, we will focus on JSF 1.2. We’ll see that many features defined in the JSF 2.0 standard are already available in JSF 1.2 through one of the many subprojects of MyFaces.
You may have noticed that there is no chapter on the MyFaces Core project in this book. This has to do with the fact that the MyFaces Core project implements only the JSF standard. That means that discussing the Core project in detail would be more or less the same as discussing the JSF standard in detail, and that is beyond the scope of this book. However, some good books on JSF are available, and you can refer to them. Of course, we will discuss specific issues that we will come across when using MyFaces Core as a JSF implementation on our application server. These issues will be discussed in Chapter 2, Getting Started.
Tomahawk has been part of the Apache MyFaces project from the very beginning. Its main goal is to implement a larger set of components than the rather minimal set that is defined in the JSF specification. Tomahawk contains both extended versions of standard JSF components and components that are not defined at all in the standard. Some examples of components that are added by Tomahawk are:
Tomahawk also features some custom validators that make it easy to validate, for instance, credit card numbers and email addresses.
There are two variants of Tomahawk, as follows:
We will take a detailed look at Tomahawk and all of its components in Chapter 4.
The MyFaces project also has a subproject called Sandbox. The Sandbox project is a testing ground for new JSF components that might be added to Tomahawk in the future. Sandbox components are generally "work in progress" and are generally not "feature complete". Sandbox components may or may not be promoted to the main Tomahawk project.
Due to the dynamic character of the project and the uncertain status of its contents, it doesn’t make sense to cover it in a book. However, if you’re looking for a special or advanced component that cannot be found in one of the other component sets, it may be worth looking in the Sandbox. You should realize that it might be harder to get support for Sandbox components, and that there is some uncertainty about their future. On the other hand, you might be able to help to get the component to production quality so that it could be promoted to Tomahawk.
Trinidad is a very extensive set of JSF components. It was developed by Oracle under the name ADF Faces. When Oracle donated this component set to the ADF Faces project, it was renamed to Trinidad. As with the Core project, there are two versions of Trinidad for each version of the JSF standard. Trinidad releases numbered 1.0.x are compatible with JSF 1.1, and releases numbered 1.2.x are compatible with JSF 1.2.
Some of the most important characteristics of Trinidad are:
It has a large number of components. There is a component for nearly everything, in Trinidad.
It has many "all-in-one" components. Some of the Trinidad components render multiple elements. With some other component sets, we need several components to get the same effect.
It has advanced skinning possibilities.
It has a lot of advanced options for displaying tabular and hierarchical data.
It has a chart component, making it fairly easy to display numeric data in a visual way.
It has a dialog framework, making it easy to create pop-up dialogs.
"Partial page rendering", client-side validation and conversion, and other AJAX functionality are embedded in most components and is easy to add where needed.
MyFaces Trinidad will be covered in detail in Chapters 5, 6, and 7.
Tobago is the third set of components that is a part of MyFaces. Tobago was contributed to the MyFaces project by a German company, Atanion GmbH. The emphasis is on separating structure from design. Tobago offers the same concept of extended components as Trinidad does, with one component rendering several elements. It also uses the concept of a layout manager, a little bit like "good old" Swing does. Tobago comes with four different themes that you can choose from. Unfortunately, there is not enough space in this book to cover this third component library.
MyFaces Orchestra is aimed at making it easier to use transactions to persist data in a database. To achieve this, extended scopes are provided, in addition to JSF’s standard application, session, and request scopes. Orchestra is mainly useful in applications where a lot of data is entered into a database with a JSF frontend. Whereas the standard JSF scopes are based on how a web server works, Orchestra focuses on what a lot of applications need, and adds a Conversation Scope, making it easier to keep certain actions within the same Java Persistence API (JPA) transaction, whether they are on the same page or not. Orchestra is based on parts of the Spring 2.0 framework and works with JPA-based persistence layers. Orchestra is covered in Chapter 9 of this book.
Portlet Bridge is one of the newer subprojects of the MyFaces project. It is still in the alpha stage at the time of writing this book. It will be the reference implementation of the JSR 301 standard. The JSR 301 standard is an effort to standardize the way that JSF artifacts (pages or parts of pages) can be used as portlets within a portal environment. Considering the stage of both the JSR 301 standard and the Portlet Bridge subproject, it will not be covered in this book.
The Validator project was recently added under the MyFaces Extensions umbrella project. This project was created as a separate project by its lead developer under a different name, but joined the MyFaces project in December 2008. Although the full name of the project is MyFaces Extensions Validator, it is mostly referred to as ExtVal.
The goal of ExtVal is to eliminate the need to repeat validation code in the View layer of a Java EE application. This is often necessary in order to give user-friendly error messages. However, according to the Don't Repeat Yourself (DRY) principle, repeating code is not desirable. ExtVal uses standard JPA annotations to dynamically create JSF validations. It also adds some extra annotations for cases where a validation cannot be expressed in a JPA annotation. Thus, ExtVal eliminates the need to add validators to JSF pages as well as the need to repeat validation code.
It should be noted that there is a JSR with number 303 that aims to achieve a comparable goal. JSR 303 is called bean validation, and will be part of Java EE 6.0. ExtVal will be compatible with JSR 303 and already goes beyond what is possible with a bare JSR 303 implementation. ExtVal will be discussed in detail in Chapter 10.