Re: Inline validation method

[Simon Kitching]

Thanks David.

Is this "validator" attribute something added in JSF 1.2? I'm sure it 
doesn't exist in JSF 1.1 (which is what MyFaces 1.1.x supports).

The article doesn't specify what JSF version each of the demonstrated 
features is available in..

Cheers, Simon

David Chandler wrote:
FYI, here's the link to the original article:

http://www-128.ibm.com/developerworks/library/j-jsf3/

It simply illustrates inline validation in JSF 1.1, and Simon is
correct that the bean validator method gets passed a component
reference (along with faces context, and an Object value to validate).

In practice, the easiest way to code the correct signature for a bean
validator method is to use your IDE to auto-create the validate()
method by having your managed bean implement the
javax.faces.validator.Validator interface. The bean doesn't actually
have to implement the interface, nor does the method have to be named
validate, but it's a convenient way to create the code.

/dmc

On 1/2/07, Simon Kitching <[EMAIL PROTECTED]> wrote:
lightbulb432 wrote:
> The text below is a modified excerpt from the IBM article about JSF
> validation...I'm wondering what exactly they're trying to say. What 
do they
> mean by the "value [has] to be generically evaluated with a component
> association in lieu of directly inspecting the local bean
> properties"...what's the issue here?

It would be nice if you gave a URL to the quoted article. I guess this
is some IBM proposal to add a feature to JSF (presumably for the JSF 1.3
or 2.0 releases).

At the point that validation runs, the "update model" phase has not
executed. So if you were to try to access the managed-bean property
specified in the "value" attribute, it wouldn't yet have the new value.
This is really the *point* of validation - checking before updating 
model.

So to get the value to be validated, you must ignore whatever the
"value" attribute points to, and instead get the data directly out of
the JSF component.

I presume their proposed "validator" method gets passed the relevant
UIComponent object (an HtmlInputText in this case).

>
>
>
> The method would then be used in the JSF tag via the validator 
attribute as
> shown here:
>
>   <h:inputText id="email"
>                value="#{UserRegistration.user.email}"
>                validator="#{UserRegistration.validateEmail}"
>                required="true">
>   </h:inputText>
>
> The validateEmail method is used by JSF to perform custom validation 
on an
> inputText component value bound to a user.email model property. If the
> e-mail format is invalid, then a message is added to the faces 
context for
> the associated component. Now, considering that this validation 
method is
> actually part of the backing bean, why does the value have to be 
generically
> evaluated with a component association in lieu of directly 
inspecting the
> local bean properties? For a hint, look at the prior lifecycle figures.
> Don't worry if you can't quite figure it out right now; we'll 
explain it all
> at the end of the article.
>
> Why, if a validation method is actually part of a backing bean, must 
its
> value be generically evaluated with a component association?
>
> The trick here is that, although the validateEmail inline validation 
method
> is part of the actual backing bean, the method must reference the 
value via
> component association rather than accessing the local properties 
directly.
> Because validation occurs before the component values are bound to 
the model
> (in the update model values phase), the model is in an unknown state.
> Therefore, you must write the inline custom validation logic as if 
it were
> dealing with validation in a custom Validator object. This is also 
explains
> the requirement of maintaining the same method signature.