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:

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:

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.