Apache MyFaces 1.2

Web Application Development

Hypes and trends (such as Web 2.0) cause a change in the requirements for user
interfaces every now and then. Although a lot of frameworks are capable of meeting
these changing requirements, they often mean that you, as a developer, need in-depth
knowledge of web standards, such as XHTML and JavaScript. Apache MyFaces hides all
of the details of how the page is rendered at the client, and at the same time offers a rich
set of tools and building blocks. This can save you a lot of time not only when you’re
building a brand-new application, but also when you’re adapting an existing application
to meet new user interface requirements.

This book will teach you everything that you need to know in order to build appealing
web interfaces with Apache MyFaces, and to maintain your code in a pragmatic way. It
describes all of the steps that are involved in building a user interface with Apache
MyFaces. This includes building templates and composition components with Facelets,
and using all sorts of specialized components from the Tomahawk and Trinidad
component sets. Adding validation with MyFaces Extensions Validator as well as using
MyFaces Orchestra to manage transactions in a page fl ow, are also covered.

Unlike comparable books, this book not only introduces Facelets as an alternative to JSP,
but actually uses Facelets in all the examples throughout this book. This makes the book
a valuable resource for Facelets examples. The book also shows how various components
of the MyFaces project can be used together, in order to deliver the functionality of the
new JSF 2.0 standard, in current projects, without the need to upgrade
your project to JSF 2.0.

This book uses a step-by-step approach, and contains a lot of tips based on experience of
the MyFaces libraries in real-world projects. Throughout the book, an example scenario
is used to work towards a fully-functional application by the end of this book.

This step-by-step guide will help you to build a fully-functional and powerful application.

What This Book Covers

Chapter 1, Introduction, introduces the Apache MyFaces project and all of its
subprojects. Forward references to other chapters are given wherever applicable.

Chapter 2, Getting Started, discusses downloading and installing the MyFaces libraries.
The set-up of two specific IDEs is discussed, as well as the set-up of an application
server for testing. This chapter also covers the use of Maven and the Maven artifacts that
are provided by the MyFaces project.

Chapter 3, Facelets, covers the installation of Facelets into our project. It discusses the
benefits of Facelets over JavaServer Pages as a view technology for JavaServer Faces.
This chapter also introduces the most important features of Facelets. By the end of the
chapter, we have created a layout template that we can use throughout the book, when
developing our application. We will also have learned the basic Facelets techniques that
we will use in all examples throughout the book.

Chapter 4, Tomahawk, looks at the Tomahawk component set that is a part of MyFaces.
Some of the most important components from the set are covered, and we will learn how
we can use these in an optimal way, in combination with Facelets. This chapter gives us
enough information to build fully-functional JSF pages by using Tomahawk components.

Chapter 5, Trinidad—the Basics, is the first of three chapters covering MyFaces
Trinidad. This chapter introduces a lot of Trinidad components, including the data input
and output components. Special attention is given to the many layout components that are
available in the Trinidad library. As with Tomahawk, we will see how we can get the
most out of the combination of Trinidad and Facelets.

Chapter 6, Advanced Trinidad, introduces some more advanced features of the Trinidad
library. This includes the charting component that can be used to easily create nice
looking charts. Also, Trinidad’s page fl ow scope feature, which enables us to create page
fl ows more easily, is introduced. This chapter also discusses the AJAX or Partial Page
Rendering capabilities of Trinidad, including client-side validation and conversion. The
Trinidad dialog framework is also covered.

Chapter 7, Trinidad Skinning and Tuning, is an introduction to the advanced skinning
framework that is a part of Trinidad. This chapter also discusses the most important
tuning parameters of Trinidad.

Chapter 8, Integrating with the Backend, discusses how we can integrate the frontend that
we created with some backend system, in a standard way. This chapter gives us some
basic knowledge about the Model-View-Controller architecture, and about important
standards such as Enterprise Java Beans (EJB) and the Java Persistence API (JPA). We
will use the knowledge and examples from this chapter as a starting point for the more
advanced integration topics discussed in the subsequent chapters.

Chapter 9, MyFaces Orchestra, introduces the MyFaces Orchestra library. This chapter
starts with a very brief introduction to the Spring framework, as Orchestra is based on
parts of that framework. We see how we can create a Spring application context and then
how we should use such a context in combination with Orchestra. Some key concepts of
Orchestra are introduced, such as the Orchestra ViewController concept and the concept
of conversations. This chapter concludes with a quick view of Orchestra’s DynaForm
component.

Chapter 10, Extensions Validator, is about one of the latest additions to the MyFaces
project: the Extensions Validator, or ExtVal for short. This chapter starts by teaching us
how to configure our project to use ExtVal. We see how JPA annotations can be used to
automatically generate JSF validations. This chapter also shows us the extra annotations
that ExtVal offers to complement the JPA annotations. This chapter also shows how we
can use Bean Validation (JSR 303) annotations as an alternative to JPA and ExtVal
annotations. As a whole, this chapter is a good introduction to this very fl exible and
versatile member of the MyFaces family.

Chapter 11, Best Practices, is the last chapter of this book. It discusses some best
practices with JSF in general and MyFaces in particular. This chapter describes a way to
prevent direct access to page definitions, as well as a way to enable container-based
security in our JSF application. This chapter also shows how to create a login page by
using JSF components, and discusses how to use component bindings wisely. This
chapter concludes by discussing how to save the state of request-scoped components in
an elegant way.

Appendix A, XHTML Entities, lists all of the numeric entities that can be used in XML
documents. This list may be needed because Facelets files must be valid, plain XML
files, and can’t contain named entities that can be used in normal XHTML files.

Appendix B, Trinidad Tags, gives a list of all of the tags from the Trinidad library. This
can be referred to if you forget the exact name of one of the many tags. It can also be
used to determine if a certain Trinidad tag is a naming container.

Appendix C, Trinidad Text Keys, lists the keys that Trinidad uses to lookup the default
texts that are displayed on components. These keys can be used to customize or translate
the default texts.

Appendix D, Default JSF Error Messages, gives an overview of the default error messages
that are defined in the JSF standard. This list can be used if you want to customize or
translate the default messages. This may also be useful in combination with the MyFaces
Extensions Validator.

Appendix E, ExtVal Default Error Messages, contains a list of the default error messages
that are defined by the Extensions Validator for use with its custom validation
annotations. This can be useful if you want to override the default messages.

Extensions Validator

A common problem with the Model-View-Controller pattern (MVC) is that often
the Don’t Repeat Yourself (DRY) principle is violated when it comes to validation
of data. The “single source of truth” with regards to validation is often either the
Model layer or the underlying database. But to be able to give the user usable,
easy-to-understand error messages, and to give those in a timely manner, we
often need to repeat a lot of validation in the View layer.

This often leads to inconsistencies in applications when the validation code in the
Model and View layers gets out of sync. This can happen because of a changed
business rule that is implemented in the Model, but the View is not updated
accordingly. Or if the View is redesigned, unintentional changes in the validation
can occur. Even when Model and View are created at the same time but by different
engineers, crippled communication between those engineers can lead to validation
code that is out of sync.

Repeating validation logic in the View layer also breaks the DRY principle at another
level. Often, information from a certain bean can be edited in different pages in the
user interface. This means that the validation has to be repeated in all of those UI
pages. So we can end up repeating the same validation logic in different pages.

Wouldn’t it be better if we didn’t have to repeat our validation code in the View
layer while keeping usable error messages, and having the validation still taking
place on the client side? This is the main reason that the “Extensions Validator”
project was added to MyFaces. The word “Extensions” refers to the fact that this
project is not about JSF components, but rather has to be seen as an extension to the
JSF Framework. The idea is that more projects can be added in the future, as further
extensions. However, for now, Validator is the only project under the “MyFaces
Extensions” umbrella that has released any software yet. As “Extensions Validator”
is a long name, the project is most of the time referred to as “ExtVal”. We’ll use this
short name throughout this chapter.

After reading this chapter, you will be able to:

• Set up a project to use ExtVal


• Use ExtVal to generate validation based on JPA annotations


• Use ExtVal’s added annotations for additional validation


• Implement cross validation using ExtVal’s annotations


• Use ExtVal with custom JSF validators


• Create custom error messages for ExtVal validations


• Override and extend ExtVal’s default behavior


• Use Bean Validation (JSR 303) annotations in combination with ExtVal


• Use metadata to set the severity level of constraints

Setting up ExtVal

As with all other libraries, we start by downloading ExtVal and installing it in our
project. As with many other JSF libraries, the ExtVal project has different branches
for JSF 1.1 and 1.2. The first two digits of ExtVal’s version number are the JSF version
they are made for. So ExtVal 1.1.x is the xth version of ExtVal for JSF 1.1, whereas
ExtVal 1.2.x is the xth version for JSF 1.2. Versions of ExtVal are not released very
often. At the time of writing this book, only two official releases have been published
for each branch. According to the lead developer of ExtVal, a third release (1.1.3 and
1.2.3) is in the works for both branches, as well as a first release from the new JSF 2.0
branch.

Apart from stable releases, ExtVal offers snapshot builds that are created on a regular
basis. The snapshots are created manually, which gives some guarantees about the
quality compared to automatically-created daily releases. No snapshots with major
bugs will be created. According to the lead developer of ExtVal, the snapshot builds
have “milestone quality”.

Because of some issues and limitations in ExtVal 1.2.2, a snapshot build of ExtVal
1.2.3 was used while writing this chapter. A stable release of ExtVal 1.2.3 is expected
to be available soon after the publishing date of this book. Stable releases can be
downloaded from the ExtVal download site at http://myfaces.apache.org/
extensions/validator/download.html. The downloaded ZIP file will contain all
of the ExtVal modules, as listed in the next table. Note that more modules may be
added to ExtVal in future releases. It is also possible that additional support modules
will be provided by others. For example, a JSF component project may create a
support module to get the most out of its components with ExtVal.

Regarding component support modules, it is also worth mentioning the “Sandbox
890” project, which provides proof of concept implementations of support modules
for some non-MyFaces component libraries. Currently, proofs of concept are
available for IceFaces, PrimeFaces, RichFaces, and OpenFaces. The source code for
the proofs of concept can be found at http://code.google.com/p/sandbox890/
source/browse/#svn/trunk/component-support. Ready-to-use JARs can be
downloaded from http://code.google.com/p/os890-m2-repository/source/
browse/#svn/trunk/sandbox890/sandbox890/extensions/validator/
component-support-modules.

Snapshot builds of ExtVal can be downloaded from ExtVal’s Maven snapshot
repository, which can be found at http://people.apache.org/maven-snapshotrepository/
org/apache/myfaces/extensions/validator/. In the case
of snapshot builds, no single ZIP file is available, and each module has to be
downloaded separately as a JAR file. Note that if Maven is used, there is no need
to manually download the snapshots. In that case, we only have to change the
version number in the pom.xml file to a snapshot version number, and Maven will
automatically download the latest snapshot. The following table lists the URLs
within the Maven repository from where the modules can be downloaded:

URLs in this table are relative to the URL of the Maven repository that we just
saw. After each URL, 1.2.x-SNAPSHOT/ has to be appended, where 1.2.x has to
be replaced by the appropriate version number.

Once we’ve finished downloading, we can start adding the JARs to our project.
ExtVal differs in one thing from other libraries—it needs to access our Model and
View project. So we have to add the ExtVal libraries to the lib directory of the EAR,
instead of the WAR or the JAR with the entities. Some libraries that ExtVal uses have
to be moved there as well. If we don’t do this, we’ll end up with all sorts of weird
exceptions related to class-loading errors.?

Libraries that are added to the lib directory of an EAR are automatically available to
all contained WAR and JAR files. However, depending on the IDE and build system
that we are using, we may have to take some additional steps to be able to build the
WAR and JAR with dependencies to the libraries in the EAR’s lib directory.

This image shows a simplified structure of the EAR with ExtVal’s libraries added
to it. Note that the MyFaces ExtVal and dependencies node in the image actually
represents multiple JAR files. It is important to verify that none of the libraries
that are in the lib directory of the EAR are included in either the WAR or the
entities JAR. Otherwise, we could still encounter class-loading confl icts. The
following table lists all of the libraries that have to be moved into the EAR to
avoid these class-loading confl icts:

	Note that the aforementioned changes in our project structure are

	necessary only because we chose to have our Model layer in a separate

	JAR file. In smaller projects, it is often the case that the whole project

	is deployed as a single WAR file without enclosing it in an EAR. If we

	had chosen that strategy, no changes to the structure would have been

	necessary and we could have added all of the libraries to the WAR file,

	as we would do with any other library.

Other than including the necessary libraries as discussed before, no configuration is
needed to get started with ExtVal. ExtVal uses the convention over configuration
pattern extensively. That means, a lot of sensible defaults are chosen, and as long as
we’re satisfied with the defaults, no configuration is needed. The next section will get
us started with some basic ExtVal usage.

	Bug with Trinidad tables

	There’s a bug in ExtVal that can cause some weird behavior in Trinidad’s

	<tr:table> component. Only the first row will be populated with

	data, and other rows will not show any data. This happens only when a

	Facelets composite component is used to add the columns to the table—

	exactly what we do in our example application. The bug can be found

	in the JIRA bug tracker for ExtVal at https://issues.apache.org/

	jira/browse/EXTVAL-77. There’s a workaround for the bug that we

	can use until it gets fixed. Be warned that this workaround may have

	other side effects.

	This workaround is shown in the following code snippet, in which we

	have created a class called DevStartupListener:

	public class DevStartupListener extends

		AbstractStartupListener {

			@Override

			protected void init() {

				ExtValContext.getContext()

					.addGlobalProperty(ExtValRendererProxy.KEY,

						null, true);

			}

		}

	The required imports are in the org.apache.myfaces.extensions.

	validator.core package and subpackages. Register this class as a

	phase listener in the faces-config.xml file:

		<lifecycle>

			<phase-listener>

				inc.monsters.mias.workaround.DevStartupListener

			</phase-listener>

		</lifecycle>

	You’re all set, and the <tr:table> will now act as expected. Don’t

	forget to remove this workaround if the bug gets fixed in a future release

	of ExtVal.

Basic usage

After setting up ExtVal, the basic usage is very simple. Let’s explore a simple
example in our MIAS application. In our Kid.java entity, we have some JPA
annotations that map the properties of the Kid bean to a database table. Let’s take a
closer look at the lastName property of our Kid bean:

	@Column(name = "LAST_NAME", nullable = false, length = 30)

	private String lastName;

The @Column annotation maps the lastName property to the LAST_NAME column in
the database. It also shows some information that is derived from the table definition
in the database. nullable = false means the database won’t accept an empty value
in this field, and length = 30 means that no more than 30 characters can be stored in
the corresponding database column. This information could be used for validation in
our View layer. If we hadn’t used ExtVal, we would have added a required="true"
attribute to the input element in our EditKid.xhtml page. We also would have
added a <tr:validateLength> component to the input component, or we could
have set the maximumLength attribute. But all of these things would have been a
duplication of information and logic, and would thus break the DRY principle.

With ExtVal, we don’t have to duplicate this information anymore. Whenever ExtVal
encounters a nullable = false setting, it will automatically add a required="true"
attribute to the corresponding input element. In the same way, it will translate
the length = 30 from the @Column annotation into a maximumLength attribute on
the input component. The next screenshot shows ExtVal in action. (Note that all
validators, and the required and maximumLength attributes were removed from the
JSF code before the screenshot was taken.) The really nice thing about this example
is that the validations created by ExtVal make use of Trinidad’s client-side validation
capabilities. In other words, the error message is created within the user’s web
browser before any input is sent to the server.

Comments

comments