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

[Ed Burns]

>>>>> On Tue, 14 Jul 2009 19:56:11 -0400, Dan Allen <dan.j.allen at gmail.com> said:

MW> It seems blatantly obvious to me that all conversion should happen
MW> before any validation occurs. I think the current situation is
MW> ridiculous and it's the root of why multi-field validation is so
MW> screwed up to begin with.

MW> See my previous comment=E2=80=A6 The question is: when this will
MW> change. JSF 2.0 would be the right version. But I guess it's
MW> already too late for such a fundamental change in the lifecycle
MW> & separating conversation and validation.

DA> It won't be JSF 2.0. Hopefully JSF 2.1 or sooner.

>>>>> On Sun, 26 Jul 2009 00:47:35 +0200, Norbert Truchsess <norbert.truchsess at t-online.de> said:

NT> My vote goes to change this in JSF 2.1 by changing the way this is
NT> handled by separating convertion and validation into two separate steps
NT> (thus effectivly adding an additional step into the jsf lifecyle).

>>>>> On Tue, 28 Jul 2009 14:16:27 -0400, Dan Allen <dan.j.allen at gmail.com> said:

DA> 1) Validation is happening in two places, once before model update
DA> and once after, which confuses the user (they have to submit the
DA> form twice to get all the validation errors)

DA> 2) Inter-component validation is very complex and in some cases, not
DA> possible without a lot of code stealing from the implementation

DA> There are two root causes that have been identified:

DA> 1) The assumption that validation should happen before model update,
DA> thus making it possible to only partially use Bean Validator (and
DA> the like)

DA> 2) The coupling of conversion and validation in the life cycle (each
DA> component is converted then validated in turn)

DA> The second root cause is easier to solve than the first. Norbert and
DA> I (perhaps others as well) believe everything would get a whole lot
DA> simpler to start with if conversion was completed before validation
DA> began so that when inter-component validation is attempted, all
DA> values are in their converted state.

PM> However this does introduce another "layer" - if conversion fails then  
PM> the no validators get run.

Yes, that is true.

I'm ok with this, but let's enumerate some backwards compatibility
concerns.  Currently the responsibility to initiate conversion is
assigned to the UIInput.validate() method.  Within that method,
getConvertedValue() is called and the result is kept as a local variable
which is passed to validateValue().  If we were to break this process
into two separate lifecycle phases, we'd need some place to store the
return from getConvertedValue() so that it can be accessed in validate()
and passed to validateValue().  For this reason, I suggest we introduce
a new protected "convertedValue" property and rigidly define the
lifetime of this property.

Note that it is ValueHolder that has the owning reference to the
Converter.  Therefore, I think we would need to have a
processConversions() method on UIComponent, which we'd override on
UIOutput to call a new convertValue() method.  We'd move
getConvertedValue() up from UIInput to UIOutput, and make convertValue()
call it.  

PM> I believe to address both (1) and (2) we have to address this problem  
PM> anyway, as I would be very unhappy to end up with the worst case  
PM> scenario of: conversion failures -> return to user -> property  
PM> validation failures -> return to user -> cross component validation ->  
PM> return to user -> business logic error -> return to user -> render  
PM> next page.

Pete, I don't see any way around having to go back to the user.  I think
first class client side validation can make this painless.  Of course,
we would still do the same validation on the server side.  I think this
could possibly be accomodated with a JSF specific JSR-303 annotation
that is somehow indicated at the point of the constraint declaration.
Something like

public class UserBean {

@Email
@AlsoRunOnClient
string email;

public String getEmail() {...}
public void setEmail() {...}

}

We'd have another bunch of stuff in the jsf.js file, but that's why we
have staked it out, so we can add stuff to it.

PM> I think we should also check that everyone agrees that cross-component  
PM> validation should provide first class support for BOTH (a) custom JSF  
PM> validators AND (b) model based. My vote would be to require (b) and  
PM> make a best effort at (a), but I suspect other disagree ;-)

I think we should go for (b) and forget (a).

AS> solve.   For example, I think we should take a look back at use cases 
AS> like this:

AS> http://www.jroller.com/robwilliams/entry/jsf_multi_field_validation_not

AS> And try to figure out which solution (or solutions) would have helped 
AS> the obviously frustrated user solve the problem in the least painful 

And there's also this

http://insights2jsf.wordpress.com/2009/08/06/multivalidator-component-allows-validation-across-multiple-input-fields/

I like this approach for its practicality.

Ed

-- 
| ed.burns at sun.com  | office: 408 884 9519 OR x31640
| homepage:         | http://ridingthecrest.com/