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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> on Thu, 12 Aug 2004 16:23:17 GMT (http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200408.mbox/[EMAIL PROTECTED]) 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]