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

[Pete Muir]

Alex Smirnov has worked on a prototype for Hibernate Validator that  
introduces a post-model-update validation phase.

Alex, has there been much reaction in the community to this? How hard  
have we pushed it?

On 11 Jun 2009, at 21:43, Dan Allen wrote:

> Mathias,
>
> There was some discussion of multi-field and form-level validation  
> at JavaOne and therefore was on my list of items to raise with the  
> EG list. Here's where we left off.
>
> As you have noticed, multi-field validation is not in the JSF 2.0  
> specification. From the point when I joined the EG, there were no  
> proposed solutions that could be agreed on and given the importance  
> of getting this issue right, it was deferred. I have two  
> recommendations for accomplishing this requirement, which I will  
> cover in this message.
>
> You are correct that the current JSR-303 integration does not handle  
> multi-field validation. But I believe that JSR-303 can become the  
> preferred solution for multi-field validation in the future. That  
> brings me to my first recommendation.
>
> Post-update module validation:
>
> The JSR-303 integration currently works by leveraging the pre- 
> binding validation method Validator#validateValue() from the Bean  
> Validation API. This method validates all constraints placed on the  
> property if the value supplied would be assigned to the property  
> (intent). This is consistent with how the built-in validators work  
> in JSF today.
>
> However, this approach leaves behind much of the capabilities of  
> JSR-303. The remainder of the validation mechanisms in JSR-303  
> require the object to be in its final state. Therefore, I believe  
> that we need to introduce a validation step that occurs at the end  
> of the Update Model Values phase. Presumably there would be a  
> declarative way of indicating which objects or properties should be  
> passed through the Validator, perhaps using EL expressions.
>
> The one restriction is that to validate two fields against one  
> another (such as the return date must be after the departure date),  
> the properties have to be siblings (on the same class). However, it  
> would be trivial to introduce composite objects that can make  
> properties appear as siblings even if they happen to be on different  
> objects.
>
> So what is the difference between pre-binding and post-binding  
> validation? The pre-binding ensures that the value you are assigning  
> to the property is sane, to prevent difficult to catch errors such  
> as NumberFormatException. The post-binding validation is for logical  
> constraints, such as comparing dates or requiring a valid city given  
> a state selection.
>
> However, there are still cases when you might want an alternative  
> approach to JSR-303. For this case, I think the onus falls on the  
> validator to enforce the value of related fields in the form. But in  
> order for that to be a reasonable requirement, one critical change  
> must be made to JSF.
>
> Currently, conversation and validation are performed one component  
> at a time. If you want to do a multi-component validation, you need  
> to ensure that both components have been converted. This requires  
> that you put the validator on the component which is visited last in  
> the component tree. Otherwise, you have to convert and validate the  
> related component.
>
> A far better approach in my mind would be to convert all the fields,  
> then validate all the fields, in two distinct steps. Then, when you  
> are writing a validator, you can depend on the fact that all fields  
> have already been converted and the validator can focus on simply  
> validating. Then it becomes simple to develop custom validators that  
> do multi-field validation in a declarative manner.
>
> Let's discuss these two solutions. Perhaps both are needed.
>
> -Dan
>
> On Thu, Jun 11, 2009 at 8:39 AM, Werlitz, Mathias  
> <werlitz at adesso.de> wrote:
>
> Hi JSF2 group,
>
> what happened to the specification goal of "inter-component and form- 
> level validation"?
> I found no reference in the current spec. Support for field-level  
> validation only makes it quite hard to develop complex business  
> forms. Validation of one field frequently depends on values in other  
> fields of the form. There are already some strategies for solving  
> this on component or model-level, but no tightly integrated standard  
> solution. The JSR 303 integration won't solve this either.
>
> A simple example is a group of (optional) address-fields (name,  
> forename, street, city, zip ...) - if the user fills one of the  
> fields, all others are required. If the user does not fill any field  
> no address-field is required.
>
> Regards,
> Mathias Werlitz
>
>
>
>
>
>
> -- 
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://in.relation.to/Bloggers/Dan
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than  
> a week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters.  Please don't hesitate to resend a  
> message if
> you feel that it did not reach my attention.