Bug #101541
open
The data type of validator options is neither respected nor documented
0%
Description
When extending \TYPO3\CMS\Extbase\Validation\Validator\AbstractValidator to write a custom validator having options, for example when doing this in combination with ext:form, one has to specifiy the $supportedOptions array inside the validator class, like so
protected $supportedOptions = [
'optionOne' => [1, 'Some option', 'int'],
'optionTwo' => [5, 'another option', 'int']
];
Containing the type of the value as the third array element.
When I dump what is in the final values in my options ($this->getOptions() or directly $this->options) I can see that the int cast is not happening. For example, when using this in combination with ext:form the option values come from the YAML which contains strings. So my options does contain '5' instead of 5.
Shouldn't the configured option types in some way be respected (at least in the documentation of this API)? What I'm saying: I'm not even sure whether I just made a bug report, or even a feature request or simply reported missing/inconsistent documentation.
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/Extbase/Reference/Domain/Validator.html has nothing about it. What is the intention of this configuration? Is this a left-over or planned to be used in the future?
Updated by Torben Hansen over 1 year ago
As far as I can see, this was never evaluated in Extbase at some time, so the 3rd array parameter is most likely unused. Typecasting is IMO no option here, since we also have validators, which declare boolean|string|integer for the parameter, so basically the value could just be used for type hinting.
Updated by S P 5 months ago
- Subject changed from The type of validator options is not respected to The data type of validator options is neither respected nor documented
- TYPO3 Version changed from 12 to 13
Still valid on v13. The validator option API is not documented at all:
So it remains unclear what this type hinting is supposed to do, what its purpose is, or whether it is a left-over or not-yet-implemented.
It seems from a look in the code that a boolean fourth parameter can also declare options as required, which is also undocumented.
Updated by Torben Hansen 4 months ago
ยท Edited
And just to add some more confusion to this issue: There is also an undocumented 4th array index for validator options, which definies, if a validator option is required or not.
protected $supportedOptions = [
'minimum' => [0, 'Minimum length for a valid string', 'integer', true],
];
If the 4th array index in this example is true, resulting in the validator option being required when used. If no option is provided on usage, an InvalidValidationOptionsException is thrown.
Flow has it at least somehow documented in code: https://github.com/neos/flow/blob/8.3/Classes/Validation/Validator/AbstractValidator.php#L46
Maybe we could use the chance in v14 and use an array key based approach, where this is more clear (see next example)
protected $supportedOptions = [
'minimum' => [
'default' => 0,
'description' => 'Minimum length for a valid string',
'type' => 'integer',
'required' => true,
],
];
We could automatically transform the "old" index based array to the new structure in AbstractValidator and additionally implement a type check.
Updated by