Java Doc for EditableValueHolder.java in  » J2EE » myfaces-core-1.2.0 » javax » faces » component » Java Source Code / Java DocumentationJava Source Code and Java Documentation

When a component implementing this interface is rendered, the value output is (in order):

• The "submitted value" if non-null.
• The component's "local value" if non-null.
• The result of evaluating the value-binding expression with name "value" for this component.

Rendering the submitted value if non-null allows a component to redisplay a user-provided value when validation fails for the component. The submitted value is usually just the plain string extracted from the servlet request. During successful validation of the component, the submitted value is converted to an appropriate datatype, and stored as the component's "local value", and then the "submitted value" is immediately reset to null.

Rendering the "local value" if non-null allows a component to redisplay a page when validation fails for some other component; the model can't be updated unless all components have passed validation. This also allows components to work without a defined "value" value-binding expression. When all components validate, the update model phase runs; all components with "value" value-bindings store the "local value" into the specified property then reset their local value to null.

Rendering the value-binding expression named "value" allows components to display data from the user's model classes. This is the most common way a component's renderer obtains the value to display. see Javadoc of JSF Specification for more.
author:
   Manfred Geiler (latest modification by $Author: mbr $)
version:
   $Revision: 512227 $ $Date: 2007-02-27 13:25:16 +0100 (Di, 27 Feb 2007) $

This is non-null only between decode and validate phases, or when validation for the component has not succeeded.

Note that even when a component is "required", it is not an error for some form to be submitted which does not contain the component.

This is non-null only between decode and validate phases, or when validation for the component has not succeeded. Once conversion and validation has succeeded, the (converted) value is stored in the local "value" property of this component, and the submitted value is reset to null.

In addition to this validator, there may be a list of validators associated with this component.

This validator is executed after all validators in the validator list.

In addition to this listener, there may be a list of listeners associated with this component.

This listeners is executed after all listeners in the list.

Note that even when a component is "required", it is not an error for some form to be submitted which does not contain the component. It is only an error when the form submitted does contain the component, but there is no data for the component in that request. A "submitted value" of null is set during the "decode" step to represent the case where the request map has no entry corresponding to this component's id. When the decode step finds an entry in the request, but the corresponding value represents "no data" (eg an empty string for a text input field) then some special non-null value must be set for the "submitted value"; validation for "required" fields must then check for that.

It is also set to false if the validated value could not be passed to the model during the update model phase.

All input components are marked as valid during the "restore view" phase, so this will return true for components whose validation has not been executed.

In many cases the submitted value is a plain string extracted from the current servlet request object.

In cases where a component is rendered as multiple input components (eg a calendar control with separate day/month/year fields), the submittedValue may be some custom object wrapping the data. However the provided object must be able to represent all possible user input values, not just valid ones.