[jsr-314-open] inter-component and form-level validation

Pete Muir pmuir at redhat.com
Tue Jul 28 17:43:22 EDT 2009


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 ;-)




More information about the jsr-314-open-mirror mailing list