12:44 p.m.
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