Weitere Constraint-Typen und eigene Fehlermeldungen

Ein NEUES Feld priority auf Project demonstriert weitere Constraint-Typen – GENAU die gleichen Klassen wie in der Symfony-Schulung, hier erstmals mit EIGENEN, benutzerdefinierten Fehlermeldungen.

Das priority-Feld ergänzen

api/src/Entity/Project.php

use Symfony\Component\Validator\Constraints as Assert;

// ... innerhalb der Klasse:

#[ORM\Column]
#[Assert\Range(
    min: 1,
    max: 5,
    notInRangeMessage: 'Die Priorität muss zwischen {{ min }} und {{ max }} liegen.'
)]
private int $priority = 3;

public function getPriority(): int
{
    return $this->priority;
}

public function setPriority(int $priority): static
{
    $this->priority = $priority;

    return $this;
}

Achtung: {{ min }}/{{ max }} in der Fehlermeldung sind Symfony-Validator-Platzhalter, KEINE Magento-Template-Direktiven – innerhalb von PHP-Zeichenketten im Quellcode ist das VÖLLIG unproblematisch, die Warnung aus der BLOG-REWRITE-ANLEITUNG betrifft NUR HTML-Content-Felder, nicht PHP-Code.

Migration für das neue Feld

docker compose exec php bin/console make:migration
docker compose exec php bin/console doctrine:migrations:migrate --no-interaction

Die eigene Meldung testen

curl -k -X POST https://localhost/api/projects \
  -H 'Content-Type: application/json' \
  -d '{"name": "Test", "priority": 9}'

{
  "violations": [
    {"propertyPath": "priority", "message": "Die Priorität muss zwischen 1 und 5 liegen."}
  ]
}

Die EIGENE Meldung ERSETZT die englische Standard-Meldung von API Platform – AUSSCHLAGGEBEND für ein Frontend, dessen Nutzeroberfläche komplett auf Deutsch (oder Englisch, je nach Store) laufen soll, OHNE dass Symfonys interne Übersetzungsdateien gepflegt werden müssen.

Weitere nützliche Constraints im Überblick

Constraint	Prüft
`#[Assert\Choice(choices: [...])]`	Wert muss aus einer festen Liste stammen (z. B. Status-Strings)
`#[Assert\Positive]`	Zahl muss größer als null sein
`#[Assert\Email]`	Gültige E-Mail-Adresse (wichtig ab Block 6 für User)
`#[Assert\Count(min: 1)]`	Sammlung (z. B. Tags) darf nicht leer sein

Tipp: ALLE Symfony-Validator-Constraints funktionieren UNVERÄNDERT in API Platform, da darunter GENAU dieselbe symfony/validator-Komponente steckt – die OFFIZIELLE Symfony-Dokumentation zu Constraints ist damit AUCH für API Platform vollständig gültig.