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

[Alexander Smirnov]

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.
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.

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