= ~[170=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=170]~ - allow |<f:param />| as a child of |<h:commandButton />|

= [359=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=359] - allow EL in |<to-view-id />|

The following proposals and discussions relate to improvements to the validation system. There are many styles of validation and these issues try to address poor assumptions made in JSF and ways to make validation more DRY.

++ Subtree validation (481)

Moved to [Subtree validation=>wiki://64561#SubtreeValidationP1] on the JSF 2.1 page.

++ Inter-component validation

<hr/>

I (Dan) don't think that cross-field validation is a difficult problem to solve from the specification level. The reason cross-field validation is difficult today is because each field is converted individually, just prior to being validated. Therefore, when the validate() method is called on a UIInput component, there is no guarantee that any other component in the form will have been converted at that time. It depends on the relative placement of the components in the form, a fact which should not be relied on in a validator.

The current strategy puts the onus of having to convert the related field(s) on the validator that is attempting to perform a cross-field check. Naive developers will simply ignore the converters on that field. The developers that do use the proper converter logic may still get sloppy with exception handling. Refer to either the [EqualityValidator=>http://anonsvn.jboss.org/repos/seam/trunk/ui/src/main/java/org/jboss/seam/ui/validator/EqualityValidator.java] in Seam or Tomahawk to witness the ridiculous amount of code that must be used to handle all of these concerns properly.

A better way to implement validation is to first convert all of the components in the form. Once all the conversions are complete, then the validators run. An extra walk of the component tree can be avoided by putting the input components that were converted into an ordered collection (or map) and then iterating over that collection (or map) to apply the validators. Using this suggested strategy, implementing a multi-component validator is no more difficult than implementing a validator on a single component. The validator tag would need to provide some way to declaratively refer to the related components, such as by ID or value expression.

Frankly, I don't feel it is the responsibility of the specification to create a multi-component validator solution. What the specification should do is make it easy to create such a solution. With that said, I do believe it would be a good idea to implement a couple of basic multi-component validators to demonstrate 1) how it's done and 2) the ease in which it can be done with conversion and validation happening in distinct steps. Reference validators would include an equality validator (one or more components), a greater and less than validator, and perhaps a switch validator (a boolean component toggles the required flag on another component).

<hr/>

I'm not a fan of client side validation - but I really like Ajax-style validation (use server side validation, and just re-render the relevant field). But *if* client-side validation was used where possible (e.g. required fields) and then Ajax was used if not possible, and the messages just completed as necessary this would be cool!

Handling of JSF messages is also weak: A message is either global or bound to a particular component. On the view, you can show either all global messages or the message for a particular component. There is no way to say, "convert" a component-bound message to a global message. I should be able to display and bundle whatever messages I feel necessary to show in whatever location. What would really be cool is to be able to assign tags to a message so that it would be possible to group them by different aspects and possibility even use the same message in multiple places on the page by tag.

=~[451=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=451]~ - Support for a "noSelection" in h:select\*

+++Default Application Time Zone (P2)

Moved to [Default application time zone=>wiki://64561#DefaultApplicationTimeZoneP1] on the JSF 2.1 page

<hr/>

= (P1) ~[161=>https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=161]~ Allow alteration of naming container separator character