You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stewart Cambridge <st...@gmail.com> on 2005/10/13 19:26:16 UTC
[validator] Extending org.apache.commons.validator.Field
Dear All,
I'm using the commons validator with Struts and want validations to
not stop at the first failure, but to run against all fields and so
return a set of failures, not just the first one (basically, in a form
of 30 fields, if a user gets several wrong, I can see him getting
annoyed because on each form submission, the next validation failure
is reported, rather than reporting them all at once).
I found an email from Bill Siggelkow <bi...@bellsouth.net> on Thu,
12 Aug 2004 16:23:17 GMT
(http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200408.mbox/%3Ccfg5hi$79s$2@sea.gmane.org%3E)
where he hacks the Field class.
Wanting a less hacky solution I tried to extend this class, and put it
in a package that is not org.apache, but com.my.project and have found
several methods and class attributes are either package or private
access.
I wondered if this was deliberate. Would there be any harm in making
private methods protected so they can be extended?
Or is a better solution for me to submit a full fix to the org.apache
class including letting the validate(Map, Map) method take its cue
from the new
<set-property property="stopOnFirstError" value="false"/>
attribute when the validator is plugged in (which is there for the
javcascript as I understand it)
(Even so, I would still want to use protected methods, because maybe
someone else wants to extend the class...)
Or maybe this functionality is already present and I've somehow missed
it in my searching.
Many thanks,
Stewart
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[validator] Fwd: Extending org.apache.commons.validator.Field
Posted by Stewart Cambridge <st...@gmail.com>.
A follow-up after more searching. I found this at
http://junlu.com/msg/82907.html
Looks like I'm not the only one to come across this problem.
I think I forgot to mention, this is for indexed properties that I'm
having this problem.
Array Validation
2004-04-29 - By Robert Leland
BackReply: 1 2 3
> -- --Original Message Slightly rearranged -- --
> From: Glenn, Scott [mailto:Scott.Glenn@(protected)]
>
> If there are any Struts developers listening can you explain this .. is it a
> bug or by design?
Doesn 't matter. What matters is that it 's not the behavior you need right ?
If someone would like to develop and test a patch that adds an option to:
A) The <PlugIn > XML element in the struts-config.xml
This would change the default behavior to not stop validating on an
error for a given module.
or
B) The Validator.xml itself, which would require a change to the
validator.dtd, either to:
B1) The form definition, so the behavior could be changed on a
per form basis.
The Option (whenInvalid ? ) would probably have four possible
values. [stop, inherit, all].
stop = This is the current default behavior
go = This is the behavior you want, where it doesn 't stop
at the first error but attempts to validate all data.
inherit = This would inherit the behavior from the parent form.
This assumes using Validator 1.2 which has a
validator form inheritance.
module = Defers to what the modules default behavior is,
assuming that option A) is also implemented.
or
B2) The validator definition itself so it could be changed on a
per type basis.
Of these A) Is the simplest and hence the fastest to develop and hence test.
Because it?s the fastest it?s more likely to be in the
1.2.1 release because.
Long term Option B1) probably makes the most sense, but since it
requires a change to the commons Validator DTD, it won 't make it into
Struts 1.2.1 since that will be using validator 1.1.3 which will be
released this weekend.
The patch should include a unit test showing that the default behaviour
in the same as in Struts 1.1, along with tests for each option.
> Thanks,
>
> Scott.
>
>
>
>
> FYI: Looks like this is a bug/feature of Struts validation. If you have a
> List of indexed properties, it stops validating them once it has discovered
> the first error.
>
> The code below is from the Validator class - it loops around all indexed
> fields (indexedList), calling the appropriate validate rule
> (validateFieldForRule()). However if this validate rule return false into
> the "good " variable, then the method exits without completing the loop.
>
> for (int pos = 0; pos < indexedList.length; pos++)
> {
> ValidatorResults results = new ValidatorResults();
> StringTokenizer st = new StringTokenizer(field.getDepends(), ", ");
> while (st.hasMoreTokens()) {
> String depend = st.nextToken().trim();
> ValidatorAction action = (ValidatorAction) actions.get(depend);
> if (action == null) {
> log.error( "No ValidatorAction called "
> + depend
> + " found for field "
> + field.getProperty());
> return;
> }
>
> boolean good = validateFieldForRule(field, action, results, actions,
> pos);
> allResults.merge(results);
> if (!good)
> {
> return;
> }
> }
>
---------- Forwarded message ----------
From: Stewart Cambridge <st...@gmail.com>
Date: 13-Oct-2005 18:26
Subject: [validator] Extending org.apache.commons.validator.Field
To: commons-dev@jakarta.apache.org
Dear All,
I'm using the commons validator with Struts and want validations to
not stop at the first failure, but to run against all fields and so
return a set of failures, not just the first one (basically, in a form
of 30 fields, if a user gets several wrong, I can see him getting
annoyed because on each form submission, the next validation failure
is reported, rather than reporting them all at once).
I found an email from Bill Siggelkow <bi...@bellsouth.net> on Thu,
12 Aug 2004 16:23:17 GMT
(http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200408.mbox/%3Ccfg5hi$79s$2@sea.gmane.org%3E)
where he hacks the Field class.
Wanting a less hacky solution I tried to extend this class, and put it
in a package that is not org.apache, but com.my.project and have found
several methods and class attributes are either package or private
access.
I wondered if this was deliberate. Would there be any harm in making
private methods protected so they can be extended?
Or is a better solution for me to submit a full fix to the org.apache
class including letting the validate(Map, Map) method take its cue
from the new
<set-property property="stopOnFirstError" value="false"/>
attribute when the validator is plugged in (which is there for the
javcascript as I understand it)
(Even so, I would still want to use protected methods, because maybe
someone else wants to extend the class...)
Or maybe this functionality is already present and I've somehow missed
it in my searching.
Many thanks,
Stewart
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org