Feature #28399
Validation message and code should be configurable for bundled validators
| Status: | Needs Feedback | Start date: | 2011-07-22 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 0% |
|
| Category: | Validation | |||
| Target version: | - | |||
| PHP Version: | Complexity: | |||
| Has patch: | No |
Description
For custom applications the bundled validators of FLOW3 are nice but unusable if different messages and codes have to be used (e.g. for a custom Regex Validator).
It would be more flexible to have two options code and message per Validator (or multiple if more than one message is added) that can be configured by the user. Additionaly a message type ("error" or "warning") would be nice.
The code change is pretty straight forward and should be compatible to the current version:
1protected function isValid($value) {
2 ...
3 // If invalid
4 $message = isset($this->options['message']) ? $this->options['message'] : 'Default error message';
5 $code = isset($this->options['code']) ? $this->options['code'] : 12345678;
6 $this->addError($message, $code);
7}
Related issues
History
#1 Updated by Karsten Dambekalns over 3 years ago
- Category set to Validation
- Has patch set to No
#2 Updated by Bastian Waidelich over 3 years ago
Thinking about it - with the ability to use L18N for outputting the validation message, I don't think we need that feature anymore (see #33970) . So I'd suggest to close this.
If you think we do need to override the code / message I would suggest not to use "magic" options for this. Maybe we need a "ValidatorOptions" object anyways..
#3 Updated by Christian Müller over 3 years ago
- Status changed from New to Rejected
With the current state of (validation) errors you can pretty much do all that in your output by using the code and arguments.
#4 Updated by Christopher Hlubek over 3 years ago
- Status changed from Rejected to Needs Feedback
Well, actually it's not about the output. A validator is a prototype that is configured with options. To differentiate validation errors in a result object (take a regexp validator for example) it's sometimes necessary to get different codes depending on the configured instance of a validator (e.g. one code for invalid email and one for invalid zip code). This is especially interesting when building web services that translate the errors in some documented error codes.
#5 Updated by Adrian Föder over 3 years ago
like the idea. Am I right that would mean you can do
1 /**
2 * @FLOW3\Validate(type="NotEmpty")
3 * @FLOW3\Validate(type="RegularExpression", options={ "regularExpression"="/^[mf]$/", "code"="UserGender" })
4 * @var string
5 * @ORM\Column(length=1)
6 */
7 protected $gender;
1<!-- ValidationErrors.de.xlf -->
2<trans-unit id="UserGender" xml:space="preserve" ....
?
#6 Updated by Christopher Hlubek over 3 years ago
Yes, that's the idea. Right now it's not possible to treat one validator type differently regarding translations. Which makes the RegularExpressionValidator pretty useless for frontend development.
Adrian Föder wrote:
like the idea. Am I right that would mean you can do
[...]