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

Wed Aug 12 20:40:38 EDT 2009

Hi guys,

If you want my 2c as well:

1) unifying validation into one step is gonna be hard to do for JSF
2.1. 2 reasons for this:

a) Alex's suggestion might work, but not for all types of model
objects, and it adds a big overhead to applications - not sure we want
to do this.

b) Additionally, there is often a reason for not having validation in
one place at all, exactly for the reasons that you, Pete, outlined as
reasons for having them in one location: a lot of the validation can
be done client-side, so the user has minimal waiting time for the
validation results, some more can be executed on the server without
back-end interaction, which again reduces waiting-time, and for the
rest there is no chance - you will have to call some back-end service
before you know what the results are, and have maximum waiting time
and performance overhead.

If you want to have minimal waiting time for users and try to keep
them as concentrated as possible, you can never expect to have all
validation in one location, instead you should choose carefully where
to execute your validation.

2) I do think you guys are right: either adding a cross-component
validator or separating out conversion and validation in two steps is
the way to go. My +1 for either of these approaches.

regards,

Martin

On 8/3/09, Pete Muir <pmuir at redhat.com> wrote:
> 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
>
>

-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces