commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton (JIRA)" <>
Subject [jira] Updated: (VALIDATOR-116) [validator] Indexed Property Validation - javascript & non-javascript
Date Wed, 19 Jul 2006 13:22:23 GMT
     [ ]

Niall Pemberton updated VALIDATOR-116:

    Component/s: Framework

> [validator] Indexed Property Validation - javascript & non-javascript
> ---------------------------------------------------------------------
>                 Key: VALIDATOR-116
>                 URL:
>             Project: Commons Validator
>          Issue Type: Improvement
>          Components: Framework
>         Environment: Operating System: other
> Platform: All
>            Reporter: G. Wayne Kidd
>            Priority: Minor
> When an indexed property is validated (which apparently cannot happen at all for
> javascript validations - I checked the CVS), only one error is identified for
> each validation type.  There should be an error for each bad field.  With the
> current implementation, there is no way for the user to identify the source of
> the problem since it could be any one (or more) of the repeating items.  The
> comment in the javascript tag that indicates why there is no javascript for this
> case indicates that the messages can't be identified.  The right thing to do
> seems to be either to give an error parm that is the field string itself.  The
> other choice seems to me to be that you could specify a identification property
> in the xml that shows which item is failing.  For example, suppose an indexed
> object (using nested tags) has a property called lastName that is being
> validated.  If it is required and missing, there is nothing to put in the
> message.  But if there is a field in the iterator that is generated, account
> number or indexid (at worst), then that could be specified to be placed in the
> error message.  No matter what, it does not seem fair to make the user fix the
> same error with additional round-trips when we have obviously already analyzed
> the error for all of the iterations.
> Wayne

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message