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

[Pete Muir]

Hi Alex,

Interesting idea :-)

On 29 Jul 2009, at 23:24, Alexander Smirnov wrote:

> After a while, I got my early idea into a working prototype. The  
> idea is coming from ValueObject pattern. In spate of that approach  
> seems obsoleted for an application design, framework could implement  
> that transparently to developer ( with some limitations, of course ).
> The scenario for for safe object validation is:
> 1) Object validator creates clone of model at the 'PROCESS_DECODES'  
> phase. Custom resolver substitutes that cloned object for all  
> references. Prototype implementation limits that substitution to  
> components inside 'graphValidator' tag. That substitution is also  
> active during 'process validators' phase.
> 2) per-components validators detect previvious case and should  
> update cloned object with converted values passed to their  
> 'validate' method.
> 3) at the and of 'processValidators' method 'graphValidator'  
> component performs validation procedure on the cloned object. In the  
> case of error validator should send error messages to the  
> FacesContext and tell JSF to go to render response phase, as usual  
> for any other validation errors. Cloned object will be discarded in  
> any case, hence subsequent phases work with real model.
>
> In that scenario validation procedure can be performed on whole  
> objects tree without affecting a real model.
>
> Open questions and limitations:
> 1) Clone procedure. In the prototype implementation, model beans  
> should implements 'Cloneable' interface and application developer  
> have to write 'clone()' method that properly clones all bean  
> attributes, disconnect them from EntityManager ( or clean them from  
> other frameworks, if necessary ). To omit that procedure from  
> developers, validation framework ( or JSF library itself ? ) could  
> perform that procedure. Anyway, that would work for plain JavaBeans  
> only, where setter/getter methods do not perform actions that could  
> affect other parts of application.

Yes, this is a clear limitation BUT would work well for entities,  
which IMO is the 80% case of what people are doing.

Other challenges I see include performance (especially around all that  
cloning of a big object graph).

> 2) Detect cloned object in validators. It is simple in the case of  
> direct references, but indirect referenced objects ( 'var' variables  
> created by the dataTable, for example ) has no glue to distinguish  
> original and cloned objects. Frameworks like Hibernate, Seam and  
> JSR-299 wraps object by proxy, therefore they could properly clone  
> beans with some marker interface.
>
> The small example is deployed onto our demo site http://localhost:8080/beanValidatorSample/pages/graphValidation.jsf 
>  . That simple example validates model that has per-property  
> restrictions and limits total sum of property values.

Once Seam 3 is going, we should start to promote this a bit and get  
some feedback...

I will say again that I think that whatever we do with graph  
validation should be extensively developed and prototyped in the  
community before considering specifying it - we have nothing much that  
does this today.

>
> On 07/28/2009 11:16 AM, Dan Allen wrote:
>> Okay, so to restate and reignite this discussion, let me seed the  
>> topic.
>>
>> 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)
>> 2) Inter-component validation is very complex and in some cases, not
>> possible without a lot of code stealing from the implementation
>>
>> 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.
>>
>> 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. 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.
>>
>> So the floor is open to discuss a general model for handling  
>> validation.
>> Please cite use cases and case studies if necessary. We simply cannot
>> let another JSF revision go by without there being a general  
>> agreement
>> that validation is sufficient for the development of web  
>> applications.
>>
>> -Dan
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>> http://in.relation.to/Bloggers/Dan