A web application can store data of many types (such as int
, long
, date
and so on) in the model layer.
When viewed in a client browser, however, the user interface has to
present the data in a manner that can be read or modified by the user.
For example a date field in a form might represent a java.util.Date
object as a text string in the format pattern yyyy/mm/dd
. When a
user edits a date field and submits the form, the string must be
converted back to the type that is required by the application. Then the
data is validated against any rules and conditions.
First let's look at the process in the context of JavaServer Faces (JSF) life cycle phases. When the form with a filled in date field is submitted, the browser sends a request value to the server. The request value is first stored in a component object in the Apply Request Values phase as the submitted string value. In the Process Validations phase, the submitted string value is converted to a local value of the appropriate object type that is required by the application. If validation correctness checks are required, the local value is then validated against the defined rules. For example a validator might check that a user supplied date is later than the current date.
If validation or conversion fails, JSF invokes the Render Response phase
and redisplays the current page. As an application developer, you need
to add h:message
tags to display the validation or
conversion error. Suppose validation and conversion are successful, then
the Update Model phase starts and the converted and validated local
value is used to update the model.
For more information about the JSF life cycle phases, see XXX.
Let's now look at the process in the context of methods in the
Converter
and Validator
interfaces. When a component
(such as the date input field) has an attached converter, the
validate()
method calls the converter's getAsObject()
method to convert the string value to the required object type. When
there isn't an attached converter and if the component is bound to a
bean property in the model, then JSF automatically uses the converter
that has the same data type as the bean property. If conversion fails,
the submitted value is marked as invalid and JSF adds an error message
to a queue that is maintained by FacesContext
. If
conversion is successful and there are no validators attached to the
component, the converted value is stored as a local value that is later
used to update the model.
If the component has one or more attached validators, the
validate()
method first checks for a submitted value if the
required
attribute of the component is set to true. If the value
is null or a zero-length string, the component is invalidated and an
error message is placed in the queue. If there are other validators
registered on the component, they are not called at all and the current
page is redisplayed. If the submitted value is a non-null value or a
string value of at least one character, the validation process continues
and the validators are called one at a time.
If all validations are successful, the Update Model Values phase starts and the local value is used to update the model. If one of the validation fails, the current page is redisplayed. By using a local value, JSF ensures that the model is not updated until all validations have passed successfully.
A JSF application can save the state of validators and components between requests on either the client or the server. For more information, see XXX.
About Conversion and Validation Errors
About Required Values and the immediate Attribute
Using Converters and Validators in JSF
Copyright © 1997, 2004, Oracle. All rights reserved.