You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Niall Pemberton (JIRA)" <ji...@apache.org> on 2006/07/19 15:22:23 UTC
[jira] Updated: (VALIDATOR-116) [validator] Indexed Property
Validation - javascript & non-javascript
[ http://issues.apache.org/jira/browse/VALIDATOR-116?page=all ]
Niall Pemberton updated VALIDATOR-116:
--------------------------------------
Component/s: Framework
> [validator] Indexed Property Validation - javascript & non-javascript
> ---------------------------------------------------------------------
>
> Key: VALIDATOR-116
> URL: http://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 is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org