Aktuell akzeptiert unser Projekt-Formular JEDEN Wert – auch einen leeren Namen. Symfonys Validator-Komponente löst das über deklarative Constraints, die wir GENAU dort platzieren, wo sie logisch hingehören: an der Datenklasse selbst.

Eine dedizierte Datenklasse statt Array

Bisher gab $form->getData() ein Array zurück – für Validierung brauchen wir eine ECHTE PHP-Klasse mit typisierten Eigenschaften, an die sich Constraints als Attribute anheften lassen:

<?php

declare(strict_types=1);

namespace App\Form\Data;

use Symfony\Component\Validator\Constraints as Assert;

class ProjectData
{
    #[Assert\NotBlank(message: 'Bitte geben Sie einen Projektnamen ein.')]
    #[Assert\Length(
        min: 3,
        max: 100,
        minMessage: 'Der Projektname muss mindestens {{ limit }} Zeichen lang sein.',
        maxMessage: 'Der Projektname darf höchstens {{ limit }} Zeichen lang sein.',
    )]
    public string $name = '';

    #[Assert\Length(max: 1000, maxMessage: 'Die Beschreibung darf höchstens {{ limit }} Zeichen lang sein.')]
    public ?string $beschreibung = null;
}

Wir platzieren diese Klasse bewusst unter src/Form/Data/ statt src/Entity/ – in Block 4 wird ProjectData durch die echte Project-Entity ersetzt, aber das Validierungsprinzip bleibt IDENTISCH.

Den Form Type mit data_class verbinden

use App\Form\Data\ProjectData;
use Symfony\Component\OptionsResolver\OptionsResolver;

class ProjectType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $builder
            ->add('name', TextType::class, ['label' => 'Projektname'])
            ->add('beschreibung', TextareaType::class, ['label' => 'Beschreibung', 'required' => false])
        ;
    }

    public function configureOptions(OptionsResolver $resolver): void
    {
        $resolver->setDefaults(['data_class' => ProjectData::class]);
    }
}

data_class teilt dem Formular mit, WELCHE Klasse es befüllen soll – $form->getData() gibt jetzt ein ProjectData-OBJEKT zurück statt eines Arrays, UND isValid() prüft automatisch ALLE Constraints, die an dieser Klasse definiert sind.

Häufige Constraints im Überblick

Validierungsfehler werden automatisch angezeigt

Da {{ form(form) }} (Kapitel 15) Fehler bereits automatisch mit rendert, brauchen wir am Template NICHTS zu ändern – schlägt die Validierung fehl, erscheint die konfigurierte message AUTOMATISCH unter dem betroffenen Feld.

Eigene Validierungslogik: Callback-Constraint

Für Regeln, die sich nicht mit einem eingebauten Constraint abdecken lassen (z. B. "Fälligkeitsdatum darf nicht auf ein Wochenende fallen"), gibt es #[Assert\Callback]:

use Symfony\Component\Validator\Context\ExecutionContextInterface;

#[Assert\Callback]
public function validiere(ExecutionContextInterface $context): void
{
    if (str_contains($this->name, 'TODO')) {
        $context->buildViolation('Der Projektname darf nicht "TODO" enthalten.')
            ->atPath('name')
            ->addViolation()
        ;
    }
}