respect-validation/docs/rules/Sf.md

# Sf

- `Sf(Constraint $constraint)`
- `Sf(Constraint $constraint, ValidatorInterface $validator)`

Validate the input with a Symfony Validator (>=4.0 or >=3.0) Constraint.

```php
use Symfony\Component\Validator\Constraint\Iban;

v::sf(new Iban())->validate('NL39 RABO 0300 0652 64'); // true
```

This rule will keep all the messages returned from Symfony.

## Categorization

- Integrations

## Changelog

Version | Description
--------|-------------
  2.0.0 | Do not create constraints anymore
  2.0.0 | Upgraded support to version >=4.0 or >=3.0 of Symfony Validator
  0.3.9 | Created
Update documentation 2015-01-30 09:40:06 +01:00			`# Sf`

Change how "Sf" rule works Instead of creating the Symfony constraints itself "Sf" accepts an instance of "Symfony\Component\Validator\Constraint". Creating objects inside a rule, specially from an external library, makes the rule too complex and also limits the possibilities with the "Sf" rule since Symfony allows users to create complex validations (even thought their API is not as simple as ours). This commit also simplifies the way the messages are passed from Symfony to the "Sf" when only one constraint has failed; instead of passing the message of the whole constraint violation list, only the fist constraint violation message it passed. The problem that this rule will always have is that when using "Not" to invert the validation we have a way to get a proper message since Symfony Validator only return the result of constraints that failed. That's something the Respect\Validation does in a similar way and to change it a lot has to be changed. These changes were checked in "symfony/validator" 4.0 and the version was added to the "composer.json" file. Signed-off-by: Henrique Moody <henriquemoody@gmail.com> 2018-08-19 20:09:32 +02:00			- `Sf(Constraint $constraint)`
			- `Sf(Constraint $constraint, ValidatorInterface $validator)`
Update documentation 2015-01-30 09:40:06 +01:00
Change how "Sf" rule works Instead of creating the Symfony constraints itself "Sf" accepts an instance of "Symfony\Component\Validator\Constraint". Creating objects inside a rule, specially from an external library, makes the rule too complex and also limits the possibilities with the "Sf" rule since Symfony allows users to create complex validations (even thought their API is not as simple as ours). This commit also simplifies the way the messages are passed from Symfony to the "Sf" when only one constraint has failed; instead of passing the message of the whole constraint violation list, only the fist constraint violation message it passed. The problem that this rule will always have is that when using "Not" to invert the validation we have a way to get a proper message since Symfony Validator only return the result of constraints that failed. That's something the Respect\Validation does in a similar way and to change it a lot has to be changed. These changes were checked in "symfony/validator" 4.0 and the version was added to the "composer.json" file. Signed-off-by: Henrique Moody <henriquemoody@gmail.com> 2018-08-19 20:09:32 +02:00			`Validate the input with a Symfony Validator (>=4.0 or >=3.0) Constraint.`
Update documentation 2015-01-30 09:40:06 +01:00
			```php
Change how "Sf" rule works Instead of creating the Symfony constraints itself "Sf" accepts an instance of "Symfony\Component\Validator\Constraint". Creating objects inside a rule, specially from an external library, makes the rule too complex and also limits the possibilities with the "Sf" rule since Symfony allows users to create complex validations (even thought their API is not as simple as ours). This commit also simplifies the way the messages are passed from Symfony to the "Sf" when only one constraint has failed; instead of passing the message of the whole constraint violation list, only the fist constraint violation message it passed. The problem that this rule will always have is that when using "Not" to invert the validation we have a way to get a proper message since Symfony Validator only return the result of constraints that failed. That's something the Respect\Validation does in a similar way and to change it a lot has to be changed. These changes were checked in "symfony/validator" 4.0 and the version was added to the "composer.json" file. Signed-off-by: Henrique Moody <henriquemoody@gmail.com> 2018-08-19 20:09:32 +02:00			`use Symfony\Component\Validator\Constraint\Iban;`

			`v::sf(new Iban())->validate('NL39 RABO 0300 0652 64'); // true`
Update documentation 2015-01-30 09:40:06 +01:00			```

Change how "Sf" rule works Instead of creating the Symfony constraints itself "Sf" accepts an instance of "Symfony\Component\Validator\Constraint". Creating objects inside a rule, specially from an external library, makes the rule too complex and also limits the possibilities with the "Sf" rule since Symfony allows users to create complex validations (even thought their API is not as simple as ours). This commit also simplifies the way the messages are passed from Symfony to the "Sf" when only one constraint has failed; instead of passing the message of the whole constraint violation list, only the fist constraint violation message it passed. The problem that this rule will always have is that when using "Not" to invert the validation we have a way to get a proper message since Symfony Validator only return the result of constraints that failed. That's something the Respect\Validation does in a similar way and to change it a lot has to be changed. These changes were checked in "symfony/validator" 4.0 and the version was added to the "composer.json" file. Signed-off-by: Henrique Moody <henriquemoody@gmail.com> 2018-08-19 20:09:32 +02:00			`This rule will keep all the messages returned from Symfony.`

Add "Categorization" section to rule documentations Signed-off-by: Henrique Moody <henriquemoody@gmail.com> 2019-05-11 18:32:13 +02:00			`## Categorization`

			`- Integrations`

Add changelog to rules' documentation Also: - Create documentation for `Base` rule; - Increase number of rules 2017-03-27 22:04:13 +02:00			`## Changelog`

			`Version \| Description`
			`--------\|-------------`
Change how "Sf" rule works Instead of creating the Symfony constraints itself "Sf" accepts an instance of "Symfony\Component\Validator\Constraint". Creating objects inside a rule, specially from an external library, makes the rule too complex and also limits the possibilities with the "Sf" rule since Symfony allows users to create complex validations (even thought their API is not as simple as ours). This commit also simplifies the way the messages are passed from Symfony to the "Sf" when only one constraint has failed; instead of passing the message of the whole constraint violation list, only the fist constraint violation message it passed. The problem that this rule will always have is that when using "Not" to invert the validation we have a way to get a proper message since Symfony Validator only return the result of constraints that failed. That's something the Respect\Validation does in a similar way and to change it a lot has to be changed. These changes were checked in "symfony/validator" 4.0 and the version was added to the "composer.json" file. Signed-off-by: Henrique Moody <henriquemoody@gmail.com> 2018-08-19 20:09:32 +02:00			`2.0.0 \| Do not create constraints anymore`
			`2.0.0 \| Upgraded support to version >=4.0 or >=3.0 of Symfony Validator`
Add changelog to rules' documentation Also: - Create documentation for `Base` rule; - Increase number of rules 2017-03-27 22:04:13 +02:00			`0.3.9 \| Created`
Update documentation 2015-01-30 09:40:06 +01:00