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.
