Mathias,<br><br>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.<br><br>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.<br>
<br>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.<br>
<br>Post-update module validation:<br><br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br>Let's discuss these two solutions. Perhaps both are needed.<br><br>-Dan<br><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 8:39 AM, Werlitz, Mathias <span dir="ltr"><<a href="mailto:werlitz@adesso.de">werlitz@adesso.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<br>
<p><font size="2">Hi JSF2 group,<br>
<br>
what happened to the specification goal of "inter-component and form-level validation"?<br>
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.<br>
<br>
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<br>
<br>
Regards,<br>
Mathias Werlitz<br>
<br>
</font>
</p>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br><br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>
from my email. If you contact me, but don't hear back for more than a week,<br>it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters. Please don't hesitate to resend a message if<br>
you feel that it did not reach my attention.<br>