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

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