This PR was merged into the 2.5-dev branch. Discussion ---------- [WIP][Validator] New NodeTraverser implementation | Q | A | ------------- | --- | Bug fix? | yes | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | TODO | License | MIT | Doc PR | TODO This PR is ready for review. #### Todo - [x] Test extensively to avoid regressions - [x] Test more extensively - [x] Finish inline documentation - [x] Provide a layer to choose the desired API through ValidatorBuilder - [x] Provide a layer to choose the desired API through FrameworkBundle - [x] Update UPGRADE file - [x] Update CHANGELOG - [ ] Update user documentation #### Goal The goal of this PR is to be able to fix the following tickets: - [x] #6138 Simplify adding of constraint violations - [x] #7146 Support group sequences in Validator API - [x] #7432 Poorly implemented Visitor Pattern - [x] #8617 Control traversal on class level - [x] #9888 Improve support for collection validation (PR: #9988) The following tickets are probably fixed, but require testing first: - [ ] #8376 Using validation_group causes error message to display multiple times - [ ] #9939 GroupSequences still execute next group if first fail Of course, full backwards compatibility **must** be guaranteed. Other tickets I want to fix in follow-up PRs: * #3622 Constraints\Valid does not respect "groups" option * #4453 walk constraints by groups * #7700 Propagate implicit group names in constraints * #9051 Always ask value event if field isn't in the validating group * #10163 poor collection validation test coverage * #10221 TypeValidator does not enforce desired type when value is NULL * #10495 Class Valid Constraint can't be used on a Form Type #### In a nutshell The implementation removes the Visitor pattern, which was implemented badly. I tried fixing it via a NodeTraverser/NodeVisitor implementation, but performance degraded too much so I decided to remove the pattern altogether. A couple of new features and bug fixes are possible thanks to the new implementation. See below for details. #### PHP Versions PHP 5.3.8 and older does not allow to implement two different interfaces which both contain a method with the same name. This is used in the compatibility layer that supports both the old and the new API. For this reason, the compatibility layer is disabled on PHP < 5.3.9. Older PHP versions need to decide on the old API or the new API (without compatibility layer). #### Choosing the API Version The API version can be specified by one of `Validation::API_VERSION_2_4`, `Validation::API_VERSION_2_5` and `Validation::API_VERSION_2_5_BC` to `setApiVersion()` when building the validator: ```php // Old implementation $validator = Validation::createValidatorBuilder() ->setApiVersion(Validation::API_VERSION_2_4) ->getValidator(); // New implementation with BC API // Does not work on PHP < 5.3.9 $validator = Validation::createValidatorBuilder() ->setApiVersion(Validation::API_VERSION_2_5) ->getValidator(); // New implementation without BC API $validator = Validation::createValidatorBuilder() ->setApiVersion(Validation::API_VERSION_2_5_BC) ->getValidator(); ``` #### Features ##### Constraint validation as first-class citizen The new API merges `validateValue()` and `validate()`. The idea is that the validation of values against constraints should be as simple as possible. Object validation is a special case where an object is tested against the `Valid` constraint. A backwards compatibility layer is provided to use both `validate()` and `validateValue()` with the old signature. ```php // Validate against explicit constraints $violations = $validator->validate($firstName, array( new NotNull(), new Length(array('min' => 3)), )); // Validate against metadata $violations = $validator->validate($object); // Same, more expressive notation $violations = $validator->validate($object, new Valid()); // Validate each entry against its metadata $violations = $validator->validate($array); ``` ##### Aggregate violations It is now possible to call the methods of the validator multiple times and aggregate the violations to a common violation list. To do so, call `startContext()`, execute the calls and call `getViolations()` in the end to retrieve the violations: ```php $violations = $validator->startContext() ->validate($title, new NotNull()) ->validate($text, new NotNull()) ->validate($author->getName(), new NotNull()) ->getViolations() ``` Most of the time, you will want to specify a property path for each validation. Use the method `atPath()` for that: ```php $violations = $validator->startContext() ->atPath('title')->validate($title, new NotNull()) ->atPath('text')->validate($text, new NotNull()) ->atPath('author.name')->validate($author->getName(), new NotNull()) ->getViolations() ``` ##### Control the context of nested validations In Symfony <= 2.4, you can validate objects or constraints from within a constraint validator like this: ```php $this->context->validate($object); $this->context->validateValue($value, new Length(array('min' => 3))); ``` The validations will run and all violations will be added to the current context. This way, it is impossible though to validate something, inspect the result and then decide what kind of violations to add to the context. This is needed, for example, for the `Some` constraint (proposed in #9888), which should succeed if any of the validated values did *not* generate violations. For this reason, the new context API features a method `getValidator()`. This method returns the validator instance, you can use it to validate anything in a new context (as the validator always does): ```php $validator = $this->context->getValidator(); $violations = $validator->validate($object); if (count($violations) > 0) { $this->context->addViolation('The validation did not pass'); } ``` You can also explicitly start a new context: ```php $validator = $this->context->getValidator(); $violations = $validator->startContext() ->atPath('title')->validate($title, new NotNull()) ->atPath('text')->validate($text, new NotNull()) ->getViolations() ``` If you want to execute the validation in the current context, use the `inContext()` method of the validator instead: ```php // violations are added to $this->context $validator->inContext($this->context) ->atPath('title')->validate($title, new NotNull()) ->atPath('text')->validate($text, new NotNull()) ; ``` With this feature, #9888 (especially the PR for it: #9988) can be finished. ##### Custom group sequences (#7146) It is now possible to pass `GroupSequence` instances whenever you can pass a group to the validator. For example: ```php $violations = $validator->validate($object, new Valid(), new GroupSequence('Basic', 'Strict')); ``` Or in the context of the Form component: ```php $form = $this->createForm(new BlogType(), new Blog(), array( 'validation_groups' => new GroupSequence('Basic', 'Strict'), )); ``` ##### Constraint violation builders (#6138) The API for adding constraint violations was simplified: ```php $this->context->addViolation('message', array('param' => 'value')); // or $this->context->buildViolation('message') ->atPath('property') ->setParameter('param', 'value') ->setTranslationDomain('validation_strict') ->addViolation(); ``` ##### Control traversal at class level (#8617) Currently, it is possible whether to traverse a `Traversable` object or not in the `Valid` constraint: ```php /** * @Assert\Valid(traverse=true) */ private $tags = new TagList(); ``` (actually, `true` is the default) In this way, the validator will iterate the `TagList` instance and validate each of the contained objects. You can also set "traverse" to `false` to disable iteration. What if you want to specify, that `TagList` instances should always (or never) be traversed? That's currently not possible. With this PR, you can do the following: ```php /** * @Assert\Traverse(false) */ class TagList implements \IteratorAggregate { // ... } ``` #### Follow-up features Features of the follow-up PRs will be described directly there. #### Backwards compatibility I implemented a new `AbstractValidatorTest` which tests both the old and the new implementation for compatibility. I still want to extend this test to make sure we don't introduce any regressions. Almost none of the existing classes were modified (or only slightly). If users depend on the current (now "legacy") implementation, they will have the choice to continue using it until 3.0 (of course, without the new features). #### Your task Congrats, you made it till here :) If you have time, please skim over the code and give me feedback on the overall implementation and the class/method names. Again, no feedback on details yet, there are quite a few areas in the code that are still work in progress. Thanks, Bernhard [1] That means that only the nodes from the root of the graph until the currently validated node are held in memory. Commits -------ca6a722
[Validator] Converted `@deprecate` doc comment into regular doc comment68d8018
[Validator] Documented changes in the UPGRADE filesb1badea
[Validator] Fixed failing CsrfFormLoginTest0bfde4a
[Validator] Fixed misnamed method calls in FrameworkExtension3dc2b4d
[Validator] Made "symfony/property-access" an optional dependencyc5629bb
[Validator] Added getObject() to ExecutionContextInterface9b204c9
[FrameworkBundle] Implemented configuration to select the desired Validator API0946dbe
[Validator] Adapted CHANGELOG1b111d0
[Validator] Fixed typos pointed out by @cordoval7bc952d
[Validator] Improved inline documentation of RecursiveContextualValidator166d71a
[Validator] Removed unused property90c27bb
[Validator] Removed traverser implementation3183aed
[Validator] Improved performance of cache key generation029a716
[Validator] Moved logic of replaceDefaultGroup() to validateNode()2f23d97
[Validator] Reduced number of method calls on the execution context73c9cc5
[Validator] Optimized performance by calling spl_object_hash() only once per object94ef21e
[Validator] Optimized use statements1622eb3
[Validator] Fixed reference to removed class in ValidatorBuilderbe508e0
[Validator] Merged DefaultGroupReplacingVisitor and ContextUpdateVisitor into NodeValidationVisitor50bb84d
[Validator] Optimized RecursiveContextualValidatoreed29d8
[Validator] Improved performance of *ContextualValidator::validate()5c479d8
[Validator] Simplified validateNodeForGroupeeed509
[Validator] Improved phpdoc of RecursiveValidator274d4e6
[Validator] Changed ValidatorBuilder to always use LegacyExecutionContext38e26fb
[Validator] Decoupled RecursiveContextualValidator from Node23534ca
[Validator] Added a recursive clone of the new implementation for speed comparisonf61d31e
[Validator] Fixed grammar886e05e
[Validator] Removed unused use statement93fdff7
[Validator] The supported API versions can now be passed to the ValidatorBuilder987313d
[Validator] Improved inline documentation of the violation builder79387a7
[Validator] Improved inline documentation of the metadata classes01ceeda
[Validator] Improved test coverage of the Traverse constraint9ca61df
[Validator] Improved inline documentation of CascadingStrategy and TraversalStrategy524a953
[Validator] Improved inline documentation of the validators9986f03
[Validator] Added inline documentation for the PropertyPath utility classbe7f055
[Validator] Visitors may now abort the traversal by returning false from beforeTraversal()299c2dc
[Validator] Improved test coverage and prevented duplicate validation of constraints186c115
[Validator] Improved test coverage of NonRecursiveNodeTraverser822fe47
[Validator] Completed inline documentation of the Node classes and the NodeTraverserdbce5a2
[Validator] Updated outdated doc blocks8558377
[Validator] Added deprecation notese8fa15b
[Validator] Fixed the new validator API under PHP < 5.3.92936d10
[Validator] Removed unused use statement6fc6ecd
[Validator] Fixed tests under PHP<5.3.9778ec24
[Validator] Removed helper class Traversal76d8c9a
[Validator] Fixed typos4161371
[Validator] Removed unused use statementsaeb6822
[Validator] Improved visitor names08172bf
[Validator] Merged validate(), validateObject() and validateObjects() to simplify usage51197f6
[Validator] Made traversal of Traversables consistent117b1b9
[Validator] Wrapped collections into CollectionNode instances94583a9
[Validator] Changed NodeTraverser to traverse nodes iteratively, not recursivelycf1281f
[Validator] Added "Visitor" suffix to all node visitors230f2a7
[Validator] Fixed exception messagee057b19
[Validator] Decoupled ContextRefresher from ExecutionContexte440690
[Validator] Renamed validateCollection() to validateObjects()df41974
[Validator] Changed context manager to context factory26eafa4
[Validator] Removed unused use statementsbc29591
[Validator] Clearly separated classes supporting the API <2.5/2.5+a3555fb
[Validator] Fixed: Objects are not traversed unless they are instances of Traversable2c65a28
[Validator] Completed test coverage and documentation of the Node classes9c9e715
[Validator] Completed documentation of GroupManagerInterface1e81f3b
[Validator] Finished test coverage and documentation of ExecutionContextManagerfeb3d6f
[Validator] Tested the validation in a separate context718601c
[Validator] Changed validateValue() to validate() in the new APIee1adad
[Validator] Implemented handling of arrays and Traversables in LegacyExecutionContext::validate()09f744b
[Validator] Implemented BC traversal of traversables through validate()297ba4f
[Validator] Added a note why scalars are passed to cascadeObject() in NodeTraverser9b07b0c
[Validator] Implemented BC validation of arrays through validate()405a03b
[Validator] Updated deprecation notes in GroupSequence499b2bb
[Validator] Completed test coverage of ExecutionContextadc1437
[Validator] Fixed failing tests4ea3ff6
[Validator] Finished inline documentation of ExecutionContext[Interface]f6b7288
[Validator] Removed unused use statement8318286
[Validator] Completed GroupSequence implementation5fbf848
[Validator] Added note about Callback constraint to CHANGELOGc1b1e03
[Validator] Added TODO reminder8ae68c9
[Validator] Made tests green (yay!)680f1ee
[Validator] Renamed $params to $parameters321d5bb
[Validator] Throw exception if ObjectInitializer is constructed without visitors1156bde
[Validator] Extracted code for group sequence resolving into GroupSequenceResolverb1a9477
[Validator] Added ObjectInitializer visitor7e3a41d
[Validator] Moved visitors to NodeVisitor namespacea40189c
[Validator] Decoupled the new classes a bita6ed4ca
[Validator] Prototype of the traverser implementation25cdc68
[Validator] Refactored ValidatorTest and ValidationVisitorTest into an abstract validator test class
5.8 KiB
UPGRADE FROM 2.4 to 2.5
Routing
- Added a new optional parameter
$requiredSchemes
toSymfony\Component\Routing\Generator\UrlGenerator::doGenerate()
Form
-
The method
FormInterface::getErrors()
now returns an instance ofSymfony\Component\Form\FormErrorIterator
instead of an array. This object is traversable, countable and supports array access. However, you can not pass it to any of PHP'sarray_*
functions anymore. You should useiterator_to_array()
in those cases where you did.Before:
$errors = array_map($callback, $form->getErrors());
After:
$errors = array_map($callback, iterator_to_array($form->getErrors()));
-
The method
FormInterface::getErrors()
now has two additional, optional parameters. Make sure to add these parameters to the method signatures of your implementations of that interface.Before:
public function getErrors() {
After:
public function getErrors($deep = false, $flatten = true) {
PropertyAccess
-
The methods
isReadable()
andisWritable()
were added toPropertyAccessorInterface
. If you implemented this interface in your own code, you should add these two methods. -
The methods
getValue()
andsetValue()
now throw anNoSuchIndexException
instead of aNoSuchPropertyException
when an index is accessed on an object that does not implementArrayAccess
. If you catch this exception in your code, you should adapt the catch statement:Before:
$object = new \stdClass(); try { $propertyAccessor->getValue($object, '[index]'); $propertyAccessor->setValue($object, '[index]', 'New value'); } catch (NoSuchPropertyException $e) { // ... }
After:
$object = new \stdClass(); try { $propertyAccessor->getValue($object, '[index]'); $propertyAccessor->setValue($object, '[index]', 'New value'); } catch (NoSuchIndexException $e) { // ... }
A
NoSuchPropertyException
is still thrown when a non-existing property is accessed on an object or an array.
Validator
-
EmailValidator has changed to allow
non-strict
andstrict
email validationBefore:
Email validation was done with php's
filter_var()
After:
Default email validation is now done via a simple regex which may cause invalid emails (not RFC compilant) to be valid. This is the default behaviour.
Strict email validation has to be explicitly activated in the configuration file by adding
framework: //... validation: strict_email: true //...
Also you have to add to your composer.json:
"egulias/email-validator": "1.1.*"
-
ClassMetadata::getGroupSequence()
now returnsGroupSequence
instances instead of an array. The sequence implements\Traversable
,\ArrayAccess
and\Countable
, so in most cases you should be fine. If you however use the sequence with PHP'sarray_*()
functions, you should cast it to an array first usingiterator_to_array()
:Before:
$sequence = $metadata->getGroupSequence(); $result = array_map($callback, $sequence);
After:
$sequence = iterator_to_array($metadata->getGroupSequence()); $result = array_map($callback, $sequence);
-
The array type hint in
ClassMetadata::setGroupSequence()
was removed. If you overwrite this method, make sure to remove the type hint as well. The method should now acceptGroupSequence
instances just as well as arrays.Before:
public function setGroupSequence(array $groups) { // ... }
After:
public function setGroupSequence($groupSequence) { // ... }
-
The validation engine in
Symfony\Component\Validator\Validator
was replaced by a new one inSymfony\Component\Validator\Validator\RecursiveValidator
. With that change, several classes were deprecated that will be removed in Symfony 3.0. Also, the API of the validator was slightly changed. More details about that can be found in UPGRADE-3.0.You can choose the desired API via the new "api" entry in app/config/config.yml:
framework: validation: enabled: true api: auto
When running PHP 5.3.9 or higher, Symfony will then use an implementation that supports both the old API and the new one:
framework: validation: enabled: true api: 2.5-bc
When running PHP lower than 5.3.9, that compatibility layer is not supported. On those versions, the old implementation will be used instead:
framework: validation: enabled: true api: 2.4
If you develop a new application that doesn't rely on the old API, you can also set the API to 2.5. In that case, the backwards compatibility layer will not be activated:
framework: validation: enabled: true api: 2.5
When using the validator outside of the Symfony full-stack framework, the desired API can be selected using
setApiVersion()
on the validator builder:// Previous implementation $validator = Validation::createValidatorBuilder() ->setApiVersion(Validation::API_VERSION_2_4) ->getValidator(); // New implementation with backwards compatibility support $validator = Validation::createValidatorBuilder() ->setApiVersion(Validation::API_VERSION_2_5_BC) ->getValidator(); // New implementation without backwards compatibility support $validator = Validation::createValidatorBuilder() ->setApiVersion(Validation::API_VERSION_2_5) ->getValidator();