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?
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.
--
View this message in context:
http://www.nabble.com/Inline-validation-method-tf2894987.html#a8088224
Sent from the MyFaces - Users mailing list archive at Nabble.com.
