>From: "Craig McClanahan (JIRA)" <[EMAIL PROTECTED]> > > [ > http://issues.apache.org/struts/browse/SHALE-340?page=comments#action_38839 ] > > Craig McClanahan commented on SHALE-340: > ---------------------------------------- > > Looking further into the way that shale-validator is implemented today, I'm > considering being (quite a bit) more aggressive -- I'd like to improve things > at > both the API level and the tag level, while we still have a chance before a > GA > release. In particular, here's what I'm thinking: > > * o.a.c.v.CommonsValidator exposes a bunch of public and protected > methods that really belong in helper classes instead of here > (in a javax.faces.validator.Validator implementation). > > * Need to implement a bunch of new validators that Commons Validator > 1.3 supports but we do not. > > * For better usability (and integration in IDEs), provide individual > validator > implementations (and corresponding JSP tags if you use JSP as your view) > for the standard Commons Validator validations. While doing so, look at > choosing a clever tag library prefix so that the tag names can be > shortened (perhaps instead of > ). > > * At the tag level, look at combining the "foo" and "fooRange" validations > into a single validator (e.g.: > [max="value"]/>) > from the user perspective. > > * Still support the old-style generic validator, for extensibly plugging in > custom validators, but discourage its use for the standard ones. > > * Look for ways to eliminate the need to use > explicitly. You should be able to get that for free. > > * While doing the above, provide robust abstract base classes to make it > really easy for custom Commons Validator validations, and corresponding > JSF validator tags. > > It should be easy to maintain the existing tags for backwards compatibility, > but > I think we can avoid being constrained by compatibility concerns at the Java > API > level. But accomplishing the above will go a *long* ways towards satisfying a > general JSF desire for client plus server side validation support in a very > usable (for manual and IDE-assisted users) way. > > Thoughts? > I think these are all good ideas. Here are obviously issues with the clutter that is distracting from the features. Having a validator subclass for each type of rule would be more of a JSF way.
Moving the validator logic to helper classes would also allow people to use it in the validator property binding callbacks. And, the script component could be automatically added using the renderer decorator approach on the form renderer. The solution for evaluation of client side validator value binding expressions in a UIData subclass. I was not happy with the extra validator XML form use to describe the formal and actual parameters and the message parameters. I wanted to use as much of the existing shale and commons implementation. If we created wrapper callbacks like in struts, we wouldn't need this extra information but it's not as configurable. At the time, no one else had additional ideas so I just went with it. Gary
