Bug #8558

Multiple validations will append to list of errors instead of replacing list from last validation

Added by Christian Lerrahn about 5 years ago. Updated almost 5 years ago.

Status:Resolved Start date:2010-08-06
Priority:Must have Due date:
Assigned To:Karsten Dambekalns % Done:

100%

Category:Validation
Target version:TYPO3 Flow Base Distribution - 1.0 alpha 11 Estimated time:2.00 hours
PHP Version: Complexity:
Has patch: Affected Flow version:

Description

If I validate several objects one after the other and then call getErrors() the listed errors will be the set union of all errors in the different single validation processes.

This does not agree with the comments found in

Classes/Validation/Validator/ValidatorInterface.php

which state

[...]
        /**
         * Checks if the given value is valid according to the validator.
         *
         * If at least one error occurred, the result is FALSE and any errors can
         * be retrieved through the getErrors() method.
         *
         * Note that all implementations of this method should set $this->errors() to an
         * empty array before validating.
         *
         * @param mixed $value The value that should be validated
         * @return boolean TRUE if the value is valid, FALSE if an error occured
         * @api
         */
        public function isValid($value);
[...]
        /**
         * Returns an array of errors which occurred during the last isValid() call.
         *
         * @return array An array of \F3\FLOW3\Validation\Error objects or an empty array if no errors occurred.
         * @api
         */
        public function getErrors();
[...]

A piece of code like

$validator = $this->validatorResolver->getBaseValidatorConjunction('F3\Foo\Domain\Model\Bar');
if ($validator->isValid($fooBarObject)) {
} else {
 $errorMessages = '';
 foreach ($validator->getErrors() as $error) {
  $errorMessages .= $error->getPropertyName().', ';
 }
}

will not give the errors for the last instance of $fooBarObject that was validated but instead the set union of errors from all instances validated up to this point. In other words, if in the first instance the property "abc" id not validate and in the second instance the property "bla" didn't validate, the error lists will be

instance 1: abc,
instance 2: abc,bla,

instead of

instance 1: abc,
instance 2: bla,

clear-errors-patch.diff Magnifier - Patch to clear errors in F3\FLOW3\Validation\Validator\GenericObjectValidator and F3\FLOW3\Validation\Validator\ConjunctionValidator (1.2 kB) Christian Lerrahn, 2010-07-01 08:42

Associated revisions

Revision 461b47f2
Added by Karsten Dambekalns almost 5 years ago

[+BUGFIX] FLOW3 (Validation): Some validators did not reset stale errors on isValid() calls, fixes #8558.

History

#1 Updated by Christian Lerrahn about 5 years ago

Oops. That target version obviously doesn't make much sense... :( Please correct! :)

#2 Updated by Christian Lerrahn about 5 years ago

The isValid() methods of

F3\FLOW3\Validation\Validator\GenericObjectValidator

and

F3\FLOW3\Validation\Validator\ConjunctionValidator

do not reset $this->errors.

Attached patch clears $this->errors at beginning of isValid() method in these objects.

#3 Updated by Karsten Dambekalns about 5 years ago

  • Category changed from Error to Validation
  • Status changed from New to Accepted
  • Assigned To set to Karsten Dambekalns
  • Target version changed from 183 to 1.0 alpha 11
  • Start date deleted (2010-06-30)

Thanks for adding this here, was about to reply on your (old) email and remembered having seen this today...

#4 Updated by Christian Lerrahn almost 5 years ago

Are there any new developments on this? This is a bit of a show stopper for our project. :(

Does my patch make sense?

#5 Updated by Karsten Dambekalns almost 5 years ago

  • Start date set to 2010-08-06
  • Estimated time set to 2.00

Working on this, expect fix in SVN today. Some more validators miss the reset and of course we need to add an unit test for all validators...

#6 Updated by Karsten Dambekalns almost 5 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Applied in changeset r4948.

Also available in: Atom PDF