WARNING: You are browsing the documentation for Symfony 4.1 which is not maintained anymore. Consider upgrading your projects to Symfony 4.3.

How to Create a custom Validation Constraint

4.1 version

Maintained

3.4 4.2 4.3 current 4.4 master

Unmaintained

2.7 2.8 3.0 3.1 3.2 3.3 4.0

How to Create a custom Validation Constraint

How to Create a custom Validation Constraint¶

You can create a custom constraint by extending the base constraint class, Constraint. As an example you're going to create a simple validator that checks if a string contains only alphanumeric characters.

Creating the Constraint Class¶

First you need to create a Constraint class and extend Constraint:

// src/Validator/Constraints/ContainsAlphanumeric.php
namespace App\Validator\Constraints;

use Symfony\Component\Validator\Constraint;

/**
 * @Annotation
 */
class ContainsAlphanumeric extends Constraint
{
    public $message = 'The string "{{ string }}" contains an illegal character: it can only contain letters or numbers.';
}

Note

The @Annotation annotation is necessary for this new constraint in order to make it available for use in classes via annotations. Options for your constraint are represented as public properties on the constraint class.

Creating the Validator itself¶

As you can see, a constraint class is fairly minimal. The actual validation is performed by another "constraint validator" class. The constraint validator class is specified by the constraint's validatedBy() method, which includes some simple default logic:

// in the base Symfony\Component\Validator\Constraint class
public function validatedBy()
{
    return \get_class($this).'Validator';
}

In other words, if you create a custom Constraint (e.g. MyConstraint), Symfony will automatically look for another class, MyConstraintValidator when actually performing the validation.

The validator class is also simple, and only has one required method validate():

// src/Validator/Constraints/ContainsAlphanumericValidator.php
namespace App\Validator\Constraints;

use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;
use Symfony\Component\Validator\Exception\UnexpectedTypeException;

class ContainsAlphanumericValidator extends ConstraintValidator
{
    public function validate($value, Constraint $constraint)
    {
        if (!$constraint instanceof ContainsAlphanumeric) {
            throw new UnexpectedTypeException($constraint, ContainsAlphanumeric::class);
        }

        // custom constraints should ignore null and empty values to allow
        // other constraints (NotBlank, NotNull, etc.) take care of that
        if (null === $value || '' === $value) {
            return;
        }

        if (!is_string($value)) {
            throw new UnexpectedTypeException($value, 'string');
        }

        if (!preg_match('/^[a-zA-Z0-9]+$/', $value, $matches)) {
            $this->context->buildViolation($constraint->message)
                ->setParameter('{{ string }}', $value)
                ->addViolation();
        }
    }
}

Inside validate, you don't need to return a value. Instead, you add violations to the validator's context property and a value will be considered valid if it causes no violations. The buildViolation() method takes the error message as its argument and returns an instance of ConstraintViolationBuilderInterface. The addViolation() method call finally adds the violation to the context.

Using the new Validator¶

Using custom validators looks the same as using the ones provided by Symfony itself:

Annotations

// src/Entity/AcmeEntity.php
use Symfony\Component\Validator\Constraints as Assert;
use App\Validator\Constraints as AcmeAssert;

class AcmeEntity
{
    // ...

    /**
     * @Assert\NotBlank
     * @AcmeAssert\ContainsAlphanumeric
     */
    protected $name;

    // ...
}

YAML

# config/validator/validation.yaml
App\Entity\AcmeEntity:
    properties:
        name:
            - NotBlank: ~
            - App\Validator\Constraints\ContainsAlphanumeric: ~

XML

<!-- config/validator/validation.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<constraint-mapping xmlns="http://symfony.com/schema/dic/constraint-mapping"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/constraint-mapping http://symfony.com/schema/dic/constraint-mapping/constraint-mapping-1.0.xsd">

    <class name="App\Entity\AcmeEntity">
        <property name="name">
            <constraint name="NotBlank" />
            <constraint name="App\Validator\Constraints\ContainsAlphanumeric" />
        </property>
    </class>
</constraint-mapping>

PHP

// src/Entity/AcmeEntity.php
use Symfony\Component\Validator\Mapping\ClassMetadata;
use Symfony\Component\Validator\Constraints\NotBlank;
use App\Validator\Constraints\ContainsAlphanumeric;

class AcmeEntity
{
    public $name;

    public static function loadValidatorMetadata(ClassMetadata $metadata)
    {
        $metadata->addPropertyConstraint('name', new NotBlank());
        $metadata->addPropertyConstraint('name', new ContainsAlphanumeric());
    }
}

If your constraint contains options, then they should be public properties on the custom Constraint class you created earlier. These options can be configured like options on core Symfony constraints.

Constraint Validators with Dependencies¶

If you're using the default services.yaml configuration, then your validator is already registered as a service and tagged with the necessary validator.constraint_validator. This means you can inject services or configuration like any other service.

Class Constraint Validator¶

Beside validating a class property, a constraint can have a class scope by providing a target in its Constraint class:

public function getTargets()
{
    return self::CLASS_CONSTRAINT;
}

With this, the validator validate() method gets an object as its first argument:

class ProtocolClassValidator extends ConstraintValidator
{
    public function validate($protocol, Constraint $constraint)
    {
        if ($protocol->getFoo() != $protocol->getBar()) {
            $this->context->buildViolation($constraint->message)
                ->atPath('foo')
                ->addViolation();
        }
    }
}

Tip

The atPath() method defines the property which the validation error is associated to. Use any valid PropertyAccess syntax to define that property.

Note that a class constraint validator is applied to the class itself, and not to the property:

Annotations

/**
 * @AcmeAssert\ContainsAlphanumeric
 */
class AcmeEntity
{
    // ...
}

YAML

# config/validator/validation.yaml
App\Entity\AcmeEntity:
    constraints:
        - App\Validator\Constraints\ContainsAlphanumeric: ~

XML

<!-- config/validator/validation.xml -->
<class name="App\Entity\AcmeEntity">
    <constraint name="App\Validator\Constraints\ContainsAlphanumeric" />
</class>

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.