Chapter 2. Managed Beans Topics in This Chapter | -
"Definition of a Bean" on page 37 -
"Message Bundles" on page 42 -
"A Sample Application" on page 46 -
"Backing Beans" on page 53 -
"Bean Scopes" on page 54 -
"Configuring Beans" on page 57 -
"The Syntax of Value Expressions" on page 64 | A central theme of web application design is the separation of presentation and business logic. JSF uses beans 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 methods. Yet, beans can be configured and manipulated without programming. Note  | You may wonder 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 term has stuck. |
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 user interface designer to drag and drop component beans from the palette into a form. Then you can customize the components by selecting property values from a property sheet dialog (see Figure 2-1). 
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. Consider the login application in Chapter 1, shown in "A Simple Example" on page 6. A UserBean instance is configured in the faces-config.xml file: <managed-bean> <managed-bean-name>user</managed-bean-name> <managed-bean-class>com.corejsf.UserBean</managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean>
This means: Construct an object of the class com.corejsf.UserBean, give it the name user, and keep it alive for the duration of the session that is, for all requests 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 password property of the user bean: <h:inputSecret value="#{user.password}"/>
As you can see, the JSF developer does not need to write any code to construct and manipulate the user bean. The JSF implementation constructs the beans according to the managed-bean 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 assembled Because beans are so ubiquitous, we now turn to a review of those parts of the JavaBeans specification that are relevant to JSF programmers. Bean Properties 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 property is any attribute of a bean that has For example, the UserBean class of the preceding chapter has a property with name password and type String. The methods getPassword and setPassword 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 follows 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 naming pattern for property getters and setters, or it must define property descriptors. The latter approach is quite tedious and not commonly used, and we will not discuss it here. See Horstmann and Cornell, 2004, 2005. Core Java 2, vol. 2, chap. 8, for more information. Defining properties with naming patterns is straightforward. Consider the following pair of methods: public T getFoo() public void setFoo(T newValue)
The pair corresponds to a read-write property with type T and name foo. 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. The method names and signatures must match the pattern precisely. The method name must start with get or set. A get method must have no parameters. A set 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 get or set prefix. For example, getFoo gives rise to a property named foo, with the first letter turned into lower case. However, if the first two letters after the prefix are upper case, then the first letter stays unchanged. For example, the method name getURL defines a property URL and not uRL. For properties of type boolean, you have a choice of prefixes for the method that reads the property. Both public boolean isConnected()
and public boolean getConnected()
are valid names for the reader of the connected property. Note | | The JavaBeans specification also defines indexed properties, specified by method sets such as the following: public T[] getFoo() public T getFoo(int index) public void setFoo(T[] newArray) public void setFoo(int index, T newValue)
However, JSF provides no support for accessing the indexed values. |
The JavaBeans specification is silent on the behavior 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. Value Expressions Many JSF user interface components have an attribute value that lets you specify either a value or a binding 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: <h:outputText value="#{user.name}"/>
In most situations, a value expression such as #{user.name} 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 <h:inputText value="#{user.name}"/>
The property getter is invoked when the component is rendered. The property setter is invoked when the user response is processed. We will discuss the syntax of value expressions in detail under "The Syntax of Value Expressions" on page 64. Note | | JSF value expressions are related to the expression language used in JSP. Those expressions are delimited by ${...} instead of #{...}. 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.) The ${...} delimiter denotes immediate evaluation of expressions, at the time that the application server processes the page. The #{...} delimiter denotes deferred evaluation. With deferred evaluation, the application server retains the expression and evaluates 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.) | | 