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

[Dan Allen]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090611/dc02eafa/attachment.html