commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (VALIDATOR-116) Indexed Property Validation - javascript & non-javascript
Date Wed, 07 Jan 2015 00:19:34 GMT

     [ https://issues.apache.org/jira/browse/VALIDATOR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sebb closed VALIDATOR-116.
--------------------------

> Indexed Property Validation - javascript & non-javascript
> ---------------------------------------------------------
>
>                 Key: VALIDATOR-116
>                 URL: https://issues.apache.org/jira/browse/VALIDATOR-116
>             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 was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message