4:43 p.m.
On 28 Jul 2009, at 19:16, Dan Allen wrote:
Okay, so to restate and reignite this discussion, let me seed the
topic.
Thanks, I also think this is a very important issue, which we now need
to get right.
Several members of the EG and many other community members have
voiced their concern that the validation mechanism in JSF is
insufficient, particularly in regard to inter-component validation,
and needs to be rethought/redesigned in a future release. I am
deciphering two concerns.
1) Validation is happening in two places, once before model update
and once after, which confuses the user (they have to submit the
form twice to get all the validation errors)
I would argue that this is a (the?) most important requirement that
most applications have for validation - that all validation failures
are presented to the user at once. This, to me, seems like a clear
productivity win for the user, both in terms of seconds spent waiting
for the second validation phase, ease in understanding of the system
and for the work cycle of the user. The moment I have to wait for the
computer, my concentration goes, and I'm off working on something
else, often not coming back to the first task for minutes (by which
time I forgotten where I am, and the session may have timed out).
2) Inter-component validation is very complex and in some cases, not
possible without a lot of code stealing from the implementation
We certainly need to address this, and I would be very very unhappy
with any solution that did not have first class support JSR-303, Bean
Validation cross property validation.
There are two root causes that have been identified:
1) The assumption that validation should happen before model update,
thus making it possible to only partially use Bean Validator (and
the like)
2) The coupling of conversion and validation in the life cycle (each
component is converted then validated in turn)
The second root cause is easier to solve than the first. Norbert and
I (perhaps others as well) believe everything would get a whole lot
simpler to start with if conversion was completed before validation
began so that when inter-component validation is attempted, all
values are in their converted state.
I can see how this would help immensely for custom inter-component
validators, but I don't think it helps for the model-based validation
approach (like JSR-303)? (this is a real question, I'm not sure :-)
However this does introduce another "layer" - if conversion fails then
the no validators get run.
The first root cause is much more challenging because if a value
cannot be converted, and you continue into validation, you run the
risk of undefined behavior. I suppose you could say that a value
which could not be converted results in a null value being assigned
with a FacesMessage registered.
I believe to address both (1) and (2) we have to address this problem
anyway, as I would be very unhappy to end up with the worst case
scenario of: conversion failures -> return to user -> property
validation failures -> return to user -> cross component validation ->
return to user -> business logic error -> return to user -> render
next page.
But are two attempts to submit the form that result in different
validation messages really a bad thing. If you enter a bogus number
in a number field, the form will yell at you that it cannot proceed
without a number. When you enter a number, it may then turn out to
be out of range, and that to me is a logical progression.
See above, I disagree.
I think we should also check that everyone agrees that cross-component
validation should provide first class support for BOTH (a) custom JSF
validators AND (b) model based. My vote would be to require (b) and
make a best effort at (a), but I suspect other disagree ;-)