[!!!][TASK] Do not magically register validators 98/60298/12
authorAlexander Schnitzler <git@alexanderschnitzler.de>
Tue, 19 Mar 2019 14:21:54 +0000 (14:21 +0000)
committerBenni Mack <benni@typo3.org>
Mon, 17 Jun 2019 12:30:54 +0000 (14:30 +0200)
commit7f21ba476affe72c2d35621ee9b8749a836ea11e
tree72a459dd7b8af47f42fdcee34ade794d6685762c
parent72d857f32655740d827b9d6eafbab45b54eeddd4
[!!!][TASK] Do not magically register validators

This patch removes the automatical registration of two types
of validators.

- model validators
- type validators

Model validators are those validators that follow a specific
namespace and class naming derived from domain models.

Given a model \Vendor\Extension\Domain\Model\Foo, extbase searched
for a valiator \Vendor\Extension\Domain\Validator\FooValidator.

If it existed, it had been registered automatically and could not
be disabled at all.

Type validators are similiar to model validators. Given a non
model action parameter or model property like int, string, float,
DateTime and such, extbase searched for validators in the
namespace TYPO3\CMS\Extbase\Validation\Validator.

There is a TYPO3\CMS\Extbase\Validation\Validator\StringValidator
for example which had been registered for string type params and
properties.

Said validators could not be disabled at all.

There are several reasons why the automatic registration has been
removed:

- First of all, this behaviour led to an unknown amount of actual
  registered validators. Developers that are new or simply not
  familiar with the concept of validation magic could easily
  become frustrated.

- Then there is the problem that validation takes place, no matter
  if it was needed or wanted. A domain validator, which looked
  quite handy in the first place, had to be reduced to the
  validation logic that would fit all cases where according
  objects had been passed into methods. No matter the context.
  The context however matters a lot. One might want to have
  different validation rules depending on if objects are
  created, updated or deleted. This distinction was impossible
  and therefore model validators could be a burden.

- Last but not least, the automatic registration is a problem
  when introducing validation groups. Validation groups cover
  the context aspect mentioned earlier. By grouping validations
  one can create and register different validators and apply
  them given by contexts like create, update, delete and such.

Releases: master
Resolves: #87957
Change-Id: If8f590a1bedb428c8884cd61828d8cc671ee92e1
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60298
Tested-by: TYPO3com <noreply@typo3.com>
Tested-by: Stefan Froemken <froemken@gmail.com>
Tested-by: Benni Mack <benni@typo3.org>
Reviewed-by: Stefan Froemken <froemken@gmail.com>
Reviewed-by: Benni Mack <benni@typo3.org>
typo3/sysext/core/Classes/Utility/ClassNamingUtility.php
typo3/sysext/core/Documentation/Changelog/master/Breaking-87957-DoNotMagicallyRegisterValidators.rst [new file with mode: 0644]
typo3/sysext/core/Tests/Unit/Utility/ClassNamingUtilityTest.php
typo3/sysext/extbase/Classes/Mvc/Controller/ActionController.php
typo3/sysext/extbase/Classes/Validation/ValidatorResolver.php
typo3/sysext/extbase/Tests/Functional/Mvc/Controller/ActionControllerTest.php
typo3/sysext/extbase/Tests/Functional/Mvc/Validation/ActionControllerValidationTest.php
typo3/sysext/extbase/Tests/Functional/Validation/ValidatorResolverTest.php
typo3/sysext/install/Configuration/ExtensionScanner/Php/MethodCallStaticMatcher.php