5:24 p.m.
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