Chapter 6. Conversion and Validation Topics in This Chapter | -
"Overview of the Conversion and Validation Process" on page 219 -
"Using Standard Converters" on page 221 -
"Using Standard Validators" on page 233 -
"Programming with Custom Converters and Validators" on page 240 | In this chapter, we discuss how form data is converted to Java objects and how the conversion results are checked for correctness. The JSF container carries out these steps before updating the model, so you can rest assured that invalid inputs will never end up in the business logic. We first look at the concepts behind the conversion and validation process. Then we discuss the standard tags that JSF provides for conversion and validation. These tags suffice for the most common needs. Next, you see how to supply your own conversion and validation code for more complex scenarios. It is also possible to implement custom tags reusable converters and validators that can be configured by page authors. However, implementing custom tags requires significantly more programming. The details are covered in "Implementing Custom Converters and Validators" on page 432 of Chapter 9. Overview of the Conversion and Validation Process Now we look at user input in slow motion as it travels from the browser form to the beans that make up the business logic. First, the user fills in a field of a web form. When the user clicks the submit button, the browser sends the form data to the server. We call this value the request value. In the Apply Request Values phase, the request values are stored in component objects. (Recall that each input tag of the JSF page has a corresponding component object.) The value stored in the component object is called the submitted value. Of course, all request values are strings after all, the client browser sends the strings that the user supplies. On the other hand, the web application deals with arbitrary types, such as int, Date, or even more sophisticated types. A conversion process transforms the incoming strings to those types. In the next section, we discuss conversion in detail. The converted values are not immediately transmitted to the beans that make up the business logic. Instead, they are first stored inside the component objects as local values. After conversion, the local values are validated. Page designers can specify validation conditions for example, that certain fields should have a minimum or maximum length. We begin our discussion of validation under "Using Standard Validators" on page 233. After all local values have been validated, the Update Model Values phase starts, and the local values are stored in beans, as specified by their value references. You may wonder why JSF bothers with local values at all. Could not one simply store the request values directly in the model? JSF uses a two-step approach to make it easier to preserve model integrity. As all programmers know only too well, users enter wrong information with distressing regularity. Suppose some of the model values had been updated before the first user error was detected. The model might then be in an inconsistent state, and it would be tedious to bring it back to its old state. For that reason, JSF first converts and validates all user input. If errors are found, the page is redisplayed with the values that the user entered so that the user can try again. The Update Model Values phase starts only if all validations are successful. Figure 6-1 shows the journey of a field value from the browser to the server-side component object and finally to the model bean. 
| 