A central theme of web application design is the separation of presentation and business logic. JSF uses
to achieve this separation. JSF pages refer to bean properties, and the program logic is contained in the bean implementation code. Because beans are so fundamental to JSF programming, we discuss them in detail in this chapter.
The first half of the chapter discusses the essential features of beans that every JSF developer needs to know. We then present an example program that puts these essentials to work. The remaining sections cover more technical aspects about bean configuration and value expressions. You can safely skip these sections when you first read this book and return to them when the need arises.
Definition of a Bean
According to the JavaBeans specification (available at http://java.sun.com/products/javabeans/), a Java bean is "a reusable software component that can be manipulated in a builder tool." That is a pretty broad definition and indeed, as you will see in this chapter, beans are used for a variety of purposes.
At first glance, a bean seems to be similar to an object. However, beans serve a different purpose. Objects are created and manipulated inside a Java program when the program calls constructors and invokes
. Yet, beans can be configured and manipulated
where the term "bean" comes from. Well, Java is a synonym for coffee (at least in the United States), and coffee is made from beans that encapsulate its flavor. You may find the analogy cute or annoying, but the
The "classic" application for JavaBeans is a user interface builder. A palette window in the builder tool contains component beans such as text fields, sliders, checkboxes, and so on. Instead of writing Swing code, you use a
interface designer to drag and drop component beans from the palette into a form. Then you can customize the
by selecting property values from a
dialog (see Figure 2-1).
Figure 2-1. Customizing a bean in a GUI builder
In the context of JSF, beans go beyond user interface components. You use beans whenever you need to wire up Java classes with web pages or configuration files.
application in Chapter 1, shown in "A Simple Example" on page 6. A
instance is configured in the
This means: Construct an object of the class
, give it the name
, and keep it
for the duration of the
—that is, for all
that originate from the same client.
Once the bean has been defined, it can be accessed by JSF components. For example, this input field reads and updates the
property of the
As you can see, the JSF developer does not need to write any code to construct and manipulate the
bean. The JSF implementation constructs the beans according to the
elements in the configuration file.
In a JSF application, beans are commonly used for the following purposes:
User interface components (traditional user interface beans)
Tying together the behavior of a web form (called "backing beans")
Business objects whose properties are displayed on web pages
Services such as external data sources that need to be configured when an application is
Because beans are so ubiquitous, we now
to a review of those
of the JavaBeans specification that are relevant to JSF programmers.
Bean classes need to follow specific programming conventions to expose features that tools can use. We discuss these conventions in this section.
The most important features of a bean are the properties that it exposes. A
is any attribute of a bean that has
For example, the
class of the
chapter has a property with name
. The methods
access the property value.
Some programming languages, in particular Visual Basic and C#, have direct support for properties. However, in Java, a bean is simply a class that
certain coding conventions.
The JavaBeans specification puts a single demand on a bean class: It must have a public default constructor—that is, a constructor without parameters. However, to define properties, a bean must either use a
for property getters and setters, or it must define property descriptors. The latter approach is quite
and not commonly used, and we will not discuss it here. See Horstmann and Cornell, 2004, 2005.
, vol. 2, chap. 8, for more information.
Defining properties with naming patterns is straightforward. Consider the following pair of methods:
public void setFoo(
The pair corresponds to a read-write property with type
. If you have only the first method, then the property is read-only. If you have only the second method, then the property is write-only.
and signatures must match the pattern precisely. The method name must start with
method must have no parameters. A
method must have one parameter and no return value. A bean class can have other methods, but the methods do not yield bean properties.
Note that the name of the property is the "decapitalized" form of the part of the method name that follows the
prefix. For example,
gives rise to a property named
, with the first letter turned into lower case. However, if the first
after the prefix are upper case, then the first letter stays unchanged. For example, the method name
defines a property
For properties of type
, you have a choice of prefixes for the method that reads the property. Both
public boolean isConnected()
public boolean getConnected()
are valid names for the reader of the
The JavaBeans specification also defines indexed properties, specified by method sets such as the following:
public void setFoo(
public void setFoo(int index,
However, JSF provides no support for accessing the indexed values.
The JavaBeans specification is silent on the
of the getter and setter methods. In many situations, these methods simply manipulate an instance field. But they may equally well carry out more sophisticated operations, such as database lookups, data conversion, validation, and so on.
A bean class may have other methods beyond property getters and setters. Of course, those methods do not give rise to bean properties.
Many JSF user interface components have an attribute
that lets you specify either a value or a
to a value that is obtained from a bean property. For example, you can specify a direct value:
<h:outputText value="Hello, World!"/>
Or you can specify a value expression:
In most situations, a value expression such as
describes a property. Note that the expression can be used both for reading and writing when it is used in an input component, such as
The property getter is invoked when the component is rendered. The property setter is invoked when the user response is
We will discuss the syntax of value expressions in detail under "The Syntax of Value Expressions" on page 64.
JSF value expressions are
to the expression language used in JSP. Those expressions are delimited by
. As of JSF 1.2 and JSP 2.1, the syntax of both expression languages has been unified. (See "The Syntax of Value Expressions" on page 64 for a complete description of the syntax.)
evaluation of expressions, at the time that the application server processes the page. The
evaluation. With deferred evaluation, the application server retains the expression and
it whenever a value is needed.
As a rule of thumb, you always use deferred expressions for JSF component properties, and you use immediate expressions in plain JSP or JSTL (JavaServer Pages Standard Template Library) constructs. (These constructs are rarely needed in JSF pages.)