[jira] Commented: (SHALE-340) Catch-all for general improvements and documentation for shale-validator

["Craig McClanahan (JIRA)" <ji...@apache.org>]

    [ 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 <validate:integer> instead of
  <val:commonsValidator type="integer"/>).

* At the tag level, look at combining the "foo" and "fooRange" validations
  into a single validator (e.g.: <validate:integer [min="value"] [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 <val:validatorScript>
  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?


> Catch-all for general improvements and documentation for shale-validator
> ------------------------------------------------------------------------
>
>                 Key: SHALE-340
>                 URL: http://issues.apache.org/struts/browse/SHALE-340
>             Project: Shale
>          Issue Type: Improvement
>          Components: Validator
>            Reporter: Craig McClanahan
>         Assigned To: Craig McClanahan
>            Priority: Minor
>             Fix For: 1.0.4-SNAPSHOT
>
>
> Catch-all ticket for general improvements to shale-validator that are surfaced during the creation and testing of a new integration test webapp (SHALE-399)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira