[
https://issues.apache.org/jira/browse/VALIDATOR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635774#action_12635774
]
Paula de Matos commented on VALIDATOR-116:
------------------------------------------
Hi,
I was just wondering if there was any more clarity on this issue. I also need
more specific error messages back in my ValidatorResults but in version 1.3.1
it still is unspecific about which element in my list caused the error. Has
this patch been applied:
http://markmail.org/message/wws4rgm3etwufs2q
Cheers,
Paula
> 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
> Fix For: Validator2
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
