Willkommen zu Teil 8 unserer Masterclass! Wenn es um professionelle Datenverarbeitung und komplexe Abläufe wie unser Strandkorb-Buchungssystem geht, sind Contao 5 Symfony Forms das ultimative Werkzeug für Entwickler. Der Kunde sieht unseren Strandkorb im Frontend, ist begeistert und möchte ihn buchen. Doch wie bekommen wir seine Daten sicher, validiert und strukturiert in unsere Datenbank?

Viele Entwickler greifen jetzt reflexartig zum klassischen Contao-Formulargenerator und versuchen, die Logik mühsam über den prepareFormData oder processFormData Hook abzufangen. Das funktioniert zwar, führt bei komplexer Business-Logik aber schnell zu unleserlichem und schwer testbarem Code.

Die moderne und professionelle Lösung in Contao 5 lautet: Contao 5 Symfony Forms. Da Contao 5 vollständig in das Symfony-Ökosystem integriert ist, können wir die mächtige Symfony Form Component nativ nutzen.

Warum Contao 5 Symfony Forms?

Objektorientierung: Ein Formular ist nicht länger ein Array aus POST-Daten, sondern ein echtes PHP-Objekt (Data Class).
Sicherheit & Validierung: CSRF-Schutz (Cross-Site Request Forgery) ist automatisch integriert. Fehlerhafte Eingaben werden durch strikte Validierungsregeln (Constraints) blockiert, bevor sie überhaupt in die Nähe der Datenbank kommen.
Trennung von Logik und Design: Die Definition der Felder (PHP), die Verarbeitung (Controller) und die Ausgabe (Twig) sind sauber getrennt.

Das ist unser Plan für dieses Modul:

Wir erstellen eine FormType-Klasse (BookingType), die die Felder unseres Buchungsformulars definiert.
Wir binden das Formular in unseren Fragment-Controller ein.
Wir rendern das Formular flexibel in unserem Twig-Template (mit Form Themes).
Wir verarbeiten den Submit, speichern die Daten über Doctrine in der Entity und versenden eine Bestätigungs-E-Mail via Symfony Mailer.

Wichtiges Vorwissen: Anders als beim Contao-Formulargenerator wird dieses Formular nicht im Backend zusammengeklickt. Es wird vollständig im Code definiert. Das macht es extrem robust und ideal für Applikationen, die nicht vom Redakteur verändert werden dürfen (ein Buchungsformular muss immer exakt diese Felder haben, sonst bricht die Datenbank-Logik zusammen).

Abstrakte Darstellung von sicherer Datenfilterung und Validierung in Contao

Lass uns in die Code-Basis springen und unsere erste Formular-Klasse schreiben!

1. Die FormType-Klasse: Struktur und Logik vereint

In der klassischen Contao-Welt klickst du dir Formulare im Backend zusammen. Das ist toll für einfache Kontaktformulare. Aber für unser Strandkorb-Buchungssystem brauchen wir absolute Kontrolle. Wir wollen sicherstellen, dass die Formulardaten exakt zu unserer Booking-Entity (die wir in Teil 4 erstellt haben) passen.

Das Herzstück der Contao 5 Symfony Forms ist der sogenannte FormType. Dies ist eine PHP-Klasse, die als Bauplan fungiert. Sie definiert, welche Felder existieren, welche Typen sie haben (Text, Datum, Zahl) und welche Validierungsregeln gelten.

Schritt 1: Den FormType anlegen

Erstelle in deinem Bundle den Ordner src/Form und darin die Datei BookingType.php:

Pfad: /src/BeachsideBundle/src/Form/BookingType.php

PHP

<?php

namespace Acme\BeachsideBundle\Form;

use Acme\BeachsideBundle\Entity\Booking;
use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\Extension\Core\Type\DateType;
use Symfony\Component\Form\Extension\Core\Type\SubmitType;
use Symfony\Component\Form\Extension\Core\Type\TextType;
use Symfony\Component\Form\FormBuilderInterface;
use Symfony\Component\OptionsResolver\OptionsResolver;

class BookingType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options): void
    {
        $builder
            ->add('customerName', TextType::class, [
                'label' => 'Ihr vollständiger Name',
                'attr' => [
                    'placeholder' => 'z.B. Max Mustermann',
                    'class' => 'form-control'
                ],
                // HTML5 required Attribut
                'required' => true, 
            ])
            ->add('dateStart', DateType::class, [
                'label' => 'Anreisedatum',
                'widget' => 'single_text', // Rendert ein modernes <input type="date">
                // Da unsere Entity Integer-Timestamps erwartet (siehe Teil 4),
                // transformiert Symfony das Datum hier automatisch, wenn konfiguriert, 
                // oder wir übergeben Datetime Objekte. Für dieses Beispiel nutzen wir den Standard.
                'input'  => 'datetime_immutable', 
                'required' => true,
            ])
            ->add('dateEnd', DateType::class, [
                'label' => 'Abreisedatum',
                'widget' => 'single_text',
                'input'  => 'datetime_immutable',
                'required' => true,
            ])
            ->add('submit', SubmitType::class, [
                'label' => 'Kostenpflichtig buchen',
                'attr' => ['class' => 'btn btn-primary mt-3']
            ])
        ;
    }

    public function configureOptions(OptionsResolver $resolver): void
    {
        $resolver->setDefaults([
            // Magic passiert hier: Wir binden das Formular an unsere Entity!
            'data_class' => Booking::class,
            
            // CSRF-Schutz ist standardmäßig aktiviert, aber hier machen wir es explizit
            'csrf_protection' => true,
            'csrf_field_name' => '_token',
            'csrf_token_id'   => 'booking_item',
        ]);
    }
}

Aufbau einer Symfony FormType Klasse mit Datenbindung

Analyse des Codes (Warum das besser ist als der Formulargenerator):

buildForm Methode: Hier nutzen wir den FormBuilder. Anstatt Tabellen in der Datenbank anzulegen, sagen wir Symfony im Code: "Ich brauche ein customerName Feld vom Typ TextType".
widget => 'single_text': Ein massiver Vorteil von Contao 5 Symfony Forms. Bei DateType rendert Symfony standardmäßig drei hässliche Dropdowns (Tag, Monat, Jahr). Mit single_text generiert es ein natives HTML5 <input type="date">, das auf mobilen Geräten den perfekten Datepicker des Betriebssystems öffnet.
configureOptions (data_class): Das ist der absolute Gamechanger! Indem wir 'data_class' => Booking::class setzen, weiß Symfony: "Ah, dieses Formular füllt ein Booking-Objekt." Wenn das Formular später abgeschickt wird, erstellt Symfony automatisch ein neues, fertiges Booking-Objekt für uns. Kein manuelles $obj->customerName = $_POST['customerName'] mehr!
CSRF-Schutz: Der Schutz vor Cross-Site Request Forgery ist direkt in die Architektur eingebaut. Das Token wird automatisch generiert und validiert.

Mit dieser Datei haben wir das komplette Fundament für unser Formular gelegt. Es ist versionskontrolliert (Git), wiederverwendbar und sicher.

2. Der Fragment Controller: Das Formular zum Leben erwecken

Unsere BookingType-Klasse ist bisher nur ein toter Bauplan. Um das Formular im Frontend anzuzeigen und abzusenden, brauchen wir einen Fragment Controller. Dieser Controller fungiert als Verkehrspolizist: Er nimmt den HTTP-Request entgegen, baut das Formular zusammen, prüft, ob es abgeschickt wurde, und leitet die Daten an die Datenbank weiter.

Wir erstellen ein neues Content-Element für unser Buchungsformular.

Pfad: /src/BeachsideBundle/src/Controller/ContentElement/BookingFormElementController.php

PHP

<?php

namespace Acme\BeachsideBundle\Controller\ContentElement;

use Acme\BeachsideBundle\Entity\Booking;
use Acme\BeachsideBundle\Form\BookingType;
use Doctrine\ORM\EntityManagerInterface;
use Contao\ContentModel;
use Contao\CoreBundle\Controller\ContentElement\AbstractContentElementController;
use Contao\CoreBundle\DependencyInjection\Attribute\AsContentElement;
use Contao\CoreBundle\Twig\FragmentTemplate;
use Symfony\Component\Form\FormFactoryInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

#[AsContentElement(category: 'beachside', template: 'content_element/booking_form')]
class BookingFormElementController extends AbstractContentElementController
{
    public function __construct(
        private readonly FormFactoryInterface $formFactory,
        private readonly EntityManagerInterface $entityManager
    ) {
    }

    protected function getResponse(FragmentTemplate $template, ContentModel $model, Request $request): Response
    {
        // 1. Eine leere Booking-Entity erstellen (oder eine bestehende laden)
        $booking = new Booking();

        // Optional: Vorbelegung der Entity, z.B. den Strandkorb aus der URL oder Session holen
        // $booking->setBeachChair($selectedChair);

        // 2. Das Formular über die FormFactory generieren
        $form = $this->formFactory->create(BookingType::class, $booking);

        // 3. Den Request an das Formular übergeben (Magie passiert hier!)
        $form->handleRequest($request);

        // 4. Prüfen, ob das Formular abgeschickt UND valide ist
        if ($form->isSubmitted() && $form->isValid()) {
            
            // $form->getData() liefert uns das fertig befüllte Booking-Objekt zurück!
            /** @var Booking $bookingData */
            $bookingData = $form->getData();

            // Zusätzliche Logik: Datum der Buchungserstellung setzen
            $bookingData->setTstamp(time());

            // Daten in der Datenbank speichern (Doctrine)
            $this->entityManager->persist($bookingData);
            $this->entityManager->flush();

            // Erfolgsmeldung im Template setzen (Alternativ: Redirect auf eine Danke-Seite)
            $template->set('success', true);
            return $template->getResponse();
        }

        // 5. Das Formular-View-Objekt an das Twig-Template übergeben
        $template->set('form', $form->createView());

        return $template->getResponse();
    }
}

Datenfluss eines Symfony Forms im Contao Fragment Controller bis zur Datenbank

Die Magie hinter dem Code (Contao 5 Symfony Forms):

FormFactoryInterface: Wir instanziieren Formulare niemals mit new BookingType(). Die FormFactory übernimmt das und injiziert alle nötigen Symfony-Abhängigkeiten (wie CSRF-Token-Generatoren).
handleRequest($request): Das ist der wichtigste Aufruf! Symfony nimmt den aktuellen POST-Request, sucht nach den Formularfeldern, validiert den CSRF-Token und – jetzt kommt das Beste – überträgt die Werte automatisch in unser $booking Objekt. Es konvertiert sogar den Datums-String aus dem HTML-Feld in ein echtes \DateTimeImmutable Objekt!
isValid(): Bevor diese Methode true zurückgibt, jagt Symfony alle Eingaben durch die Validierungsregeln. Wenn der Kunde Buchstaben in das Datumsfeld tippt, ist isValid() false und das Formular wird (inklusive Fehlermeldungen) wieder angezeigt.
$form->createView(): Wir übergeben nicht das Formular-Objekt selbst an Twig, sondern einen "View". Dieser enthält alle HTML-Attribute, Label-Texte und Fehlermeldungen, die Twig zum Rendern braucht.

Wir haben jetzt die komplette Logik für die Datenverarbeitung geschrieben. Ohne unübersichtliche Hooks, ohne manuelle $_POST-Abfragen und mit 100% typsicherem Code.

3. Das Formular in Twig rendern: Von Daten zu HTML

In unserem Controller haben wir $template->set('form', $form->createView()) aufgerufen. In unserem Twig-Template steht uns nun die Variable form zur Verfügung.

Die einfachste Art, ein Contao 5 Symfony Form auszugeben, ist ein einziger Befehl: {{ form(form) }}. Das rendert das komplette Formular inklusive <form>-Tag, allen Inputs, Labels und dem Submit-Button. Für echte Projekte reicht das aber selten aus, da wir die Struktur an unser Grid-System anpassen wollen.

Schritt 1: Das Twig Template

Erstelle die Datei /src/BeachsideBundle/templates/content_element/booking_form.html.twig:

Twig

{% extends "@Contao/content_element/_base.html.twig" %}

{# 
   FORM THEME MAGIC: 
   Wir sagen Twig, dass es für dieses Formular das Bootstrap 5 Layout nutzen soll.
   Dadurch erhalten alle Felder automatisch Klassen wie 'form-control' oder 'form-label'.
#}
{% form_theme form 'bootstrap_5_layout.html.twig' %}

{% block content %}
    <div>
        
        {% if success %}
            <div>
                <h3>Vielen Dank für Ihre Buchung!</h3>
                <p>Wir haben Ihre Anfrage erhalten und melden uns in Kürze.</p>
            </div>
        {% else %}
            
            <h3>Strandkorb jetzt buchen</h3>
            
            {# form_start generiert das <form> Tag und das CSRF-Token #}
            {{ form_start(form, {'attr': {'class': 'needs-validation'}}) }}
            
                {# Wir können Fehler für das gesamte Formular hier ausgeben #}
                {{ form_errors(form) }}

                <div>
                    <div>
                        {# form_row rendert Label, Input, Fehler und Help-Text auf einmal #}
                        {{ form_row(form.customerName) }}
                    </div>
                </div>

                <div>
                    <div>
                        {{ form_row(form.dateStart) }}
                    </div>
                    <div>
                        {{ form_row(form.dateEnd) }}
                    </div>
                </div>

                <div>
                    {# Den Submit Button manuell platzieren #}
                    {{ form_row(form.submit) }}
                </div>

            {# form_end schließt das Tag und rendert versteckte Felder (wie das CSRF-Token!) #}
            {{ form_end(form) }}
            
        {% endif %}
        
    </div>
{% endblock %}

Transformation eines ungestylten Symfony Forms in ein Bootstrap 5 Layout durch Form Themes

Warum Form Themes ein Gamechanger sind:

Wenn du ein natives Contao 5 Symfony Form ohne Form Theme renderst, sieht der HTML-Code extrem nackt aus. Es fehlen CSS-Klassen für dein Framework. In der alten Contao-Welt musstest du oft die form_widget.html5 Templates updatesicher anpassen, was schnell in Chaos endete.

Mit Symfony Form Themes ist das ein Einzeiler: {% form_theme form 'bootstrap_5_layout.html.twig' %}. Symfony liefert native Themes für Bootstrap 3, 4, 5, Foundation und Tailwind CSS mit! Sobald du das Theme aktivierst, weiß Symfony exakt, wie ein Fehler-Status in Bootstrap aussieht (is-invalid Klasse am Input, <div> für die Nachricht) und baut das HTML vollautomatisch zusammen.

Globale Form Themes: Wenn deine ganze Website Bootstrap 5 nutzt, musst du den form_theme Tag nicht in jedes Template schreiben. Du kannst ihn in der config/packages/twig.yaml global für dein gesamtes Contao-Projekt definieren:

YAML

twig:
    form_themes: ['bootstrap_5_layout.html.twig']

Zusammenfassung: Wir haben das Formular jetzt visuell in unser Frontend integriert. Die Trennung ist perfekt: Die Logik liegt im BookingType, die Verarbeitung im Controller und das reine Markup flexibel im Twig-Template.

4. Komplexe Validierung: Eigene Constraints erstellen

Bisher haben wir in unserem Contao 5 Symfony Form Standard-Validierungen genutzt: Pflichtfelder (required => true) und korrekte Datumsformate. Aber was ist mit der echten Business-Logik? Was passiert, wenn der Kunde ein Abreisedatum wählt, das vor dem Anreisedatum liegt? Oder noch schlimmer: Was, wenn der Strandkorb in diesem Zeitraum bereits ausgebucht ist?

In der alten Contao-Welt hättest du das mühsam im processFormData-Hook geprüft und das Neuladen der Seite manipuliert. Bei Contao 5 Symfony Forms nutzen wir die native Symfony Validator Component. Wir erstellen einen eigenen Constraint (eine Validierungsregel), der unser Formular blockiert, bevor die Daten die Datenbank erreichen.

Schritt 1: Die Constraint-Klasse (Das Etikett)

Ein Constraint besteht immer aus zwei Klassen. Die erste ist extrem simpel und fungiert nur als Attribut (das "Etikett"), das wir später anheften.

Erstelle src/Validator/BeachChairAvailable.php:

PHP

<?php

namespace Acme\BeachsideBundle\Validator;

use Symfony\Component\Validator\Constraint;

#[\Attribute(\Attribute::TARGET_CLASS)]
class BeachChairAvailable extends Constraint
{
    // Die Standard-Fehlermeldung
    public string $message = 'Der Strandkorb ist in diesem Zeitraum leider schon belegt.';

    // Wichtig: Wir wollen das gesamte Objekt (Start, End, Chair) prüfen, nicht nur ein einzelnes Feld.
    public function getTargets(): string|array
    {
        return self::CLASS_CONSTRAINT;
    }
}

Schritt 2: Der Constraint-Validator (Die Logik)

Jetzt kommt die Magie. Symfony sucht automatisch nach einer Klasse, die genauso heißt, aber auf Validator endet. Hier können wir dank Dependency Injection unseren AvailabilityChecker Service (aus Teil 5) nutzen!

Erstelle src/Validator/BeachChairAvailableValidator.php:

PHP

<?php

namespace Acme\BeachsideBundle\Validator;

use Acme\BeachsideBundle\Entity\Booking;
use Acme\BeachsideBundle\Service\AvailabilityChecker;
use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;
use Symfony\Component\Validator\Exception\UnexpectedTypeException;

class BeachChairAvailableValidator extends ConstraintValidator
{
    public function __construct(
        private readonly AvailabilityChecker $checker
    ) {
    }

    public function validate($value, Constraint $constraint): void
    {
        if (!$constraint instanceof BeachChairAvailable) {
            throw new UnexpectedTypeException($constraint, BeachChairAvailable::class);
        }

        // Da wir es als Class-Constraint nutzen, ist $value unsere Booking Entity!
        if (!$value instanceof Booking) {
            return;
        }

        // Wenn Felder leer sind, übernimmt das die Standard-Required-Validierung
        if (!$value->getBeachChair() || !$value->getDateStart() || !$value->getDateEnd()) {
            return;
        }

        // Datumskontrolle: Abreise vor Anreise?
        if ($value->getDateStart() >= $value->getDateEnd()) {
            $this->context->buildViolation('Das Abreisedatum muss nach dem Anreisedatum liegen.')
                ->atPath('dateEnd') // Fehler direkt an das Feld "dateEnd" heften
                ->addViolation();
            return;
        }

        // Business-Logik: Ist der Strandkorb frei?
        $isFree = $this->checker->isAvailable(
            $value->getBeachChair(), 
            $value->getDateStart(), 
            $value->getDateEnd()
        );

        if (!$isFree) {
            // Fehler an das Formular hängen
            $this->context->buildViolation($constraint->message)
                ->addViolation();
        }
    }
}

Symfony Validator Component prüft Datenpakete an einem Sicherheitsscanner

Schritt 3: Das Etikett anbringen

Da unser Contao 5 Symfony Form an die Booking-Entity gebunden ist (data_class => Booking::class), müssen wir den Constraint einfach nur als Attribut über unsere Entity-Klasse schreiben!

Öffne deine src/Entity/Booking.php (aus Teil 4) und ergänze das Attribut:

PHP

<?php

namespace Acme\BeachsideBundle\Entity;

use Acme\BeachsideBundle\Validator\BeachChairAvailable; // Importieren!
use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
#[ORM\Table(name: "tl_booking")]
#[BeachChairAvailable] // <-- HIER IST DIE MAGIE!
class Booking
{
    // ... restlicher Code ...
}

Was passiert jetzt? Wenn der User im Frontend auf "Buchen" klickt, ruft der Controller $form->handleRequest($request) und $form->isValid() auf. Symfony erkennt das Attribut #[BeachChairAvailable] auf der Entity, instanziiert unseren Validator, injiziert den AvailabilityChecker aus dem Service-Container und führt die Prüfung aus.

Ist der Strandkorb belegt, schlägt isValid() fehl und das Formular wird in Twig sofort mit der roten Fehlermeldung "Der Strandkorb ist in diesem Zeitraum leider schon belegt." gerendert. Keine inkonsistenten Datenbankeinträge, keine gehackten Formulare. Absolute Sicherheit.

5. Nach dem Submit: E-Mails mit Symfony Mailer versenden

Wenn ein Contao 5 Symfony Form erfolgreich abgeschickt (isSubmitted) und validiert (isValid) wurde, haben wir in Iteration 3 die Daten per Doctrine in der Datenbank gespeichert. Der nächste logische Schritt in jedem Buchungssystem ist die Bestätigungs-E-Mail.

Contao 5 integriert den Symfony Mailer nativ. Er ersetzt nicht nur die alte \Contao\Email Klasse, sondern bringt Enterprise-Features mit: Unterstützung für asynchronen Versand (Queueing), fertige Twig-Integration für HTML-Mails und nahtlose Anbindung an Drittanbieter (SendGrid, Mailgun) via DSN.

Schritt 1: Den Controller anpassen (Dependency Injection)

Wir öffnen unseren BookingFormElementController aus Iteration 3 und injizieren den MailerInterface. Außerdem nutzen wir die Klasse TemplatedEmail, um unsere E-Mail direkt mit einem Twig-Template zu verknüpfen.

PHP

<?php

namespace Acme\BeachsideBundle\Controller\ContentElement;

// ... bisherige Imports ...
use Symfony\Bridge\Twig\Mime\TemplatedEmail;
use Symfony\Component\Mailer\MailerInterface;
use Symfony\Component\Mime\Address;

#[AsContentElement(category: 'beachside', template: 'content_element/booking_form')]
class BookingFormElementController extends AbstractContentElementController
{
    public function __construct(
        private readonly FormFactoryInterface $formFactory,
        private readonly EntityManagerInterface $entityManager,
        private readonly MailerInterface $mailer // <-- NEU: Symfony Mailer injizieren
    ) {
    }

    protected function getResponse(FragmentTemplate $template, ContentModel $model, Request $request): Response
    {
        $booking = new Booking();
        $form = $this->formFactory->create(BookingType::class, $booking);
        $form->handleRequest($request);

        if ($form->isSubmitted() && $form->isValid()) {
            
            /** @var Booking $bookingData */
            $bookingData = $form->getData();
            $bookingData->setTstamp(time());

            $this->entityManager->persist($bookingData);
            $this->entityManager->flush();

            // --------------------------------------------------
            // NEU: E-Mail Versand aufbauen
            // --------------------------------------------------
            $email = (new TemplatedEmail())
                ->from(new Address('no-reply@beachside.de', 'Strandkorbvermietung Binz'))
                // In einer echten App würden wir die Kunden-Mail aus dem Formular holen.
                // Fürs Beispiel schicken wir es an den Admin.
                ->to('admin@beachside.de')
                ->subject('Neue Strandkorb-Buchung eingegangen!')
                
                // Pfad zum Twig-Template für die E-Mail
                ->htmlTemplate('@AcmeBeachside/emails/booking_notification.html.twig')
                
                // Variablen an das E-Mail-Template übergeben
                ->context([
                    'booking' => $bookingData,
                ]);

            // E-Mail absenden
            $this->mailer->send($email);
            // --------------------------------------------------

            $template->set('success', true);
            return $template->getResponse();
        }

        $template->set('form', $form->createView());
        return $template->getResponse();
    }
}

Architektur des Symfony Mailers mit Twig TemplatedEmail Integration

Schritt 2: Das E-Mail Twig-Template erstellen

Wir haben im Controller @AcmeBeachside/emails/booking_notification.html.twig referenziert. Wir erstellen diese Datei nun im Ordner templates/emails/.

Hier können wir wieder die volle Power von Twig nutzen.

Twig

{# templates/emails/booking_notification.html.twig #}
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Neue Buchung</title>
</head>
<body>
    <h1>Neue Strandkorb-Buchung!</h1>
    
    <p>Hallo Admin,</p>
    <p>es ist eine neue Buchung über die Website eingegangen:</p>
    
    <ul>
        <li><strong>Kunde:</strong> {{ booking.customerName }}</li>
        <li><strong>Strandkorb:</strong> Nr. {{ booking.beachChair.chairNumber }}</li>
        <li><strong>Von:</strong> {{ booking.dateStart|format_date('medium') }}</li>
        <li><strong>Bis:</strong> {{ booking.dateEnd|format_date('medium') }}</li>
    </ul>

    <p>Bitte logge dich ins Contao-Backend ein, um die Details zu prüfen.</p>
</body>
</html>

Warum das in Contao 5 besser ist: Wenn du komplexe Contao 5 Symfony Forms baust, willst du oft strukturierte HTML-E-Mails versenden. Die TemplatedEmail Klasse von Symfony ermöglicht es dir sogar, CSS inline zu rendern (mit der CssInliner Extension) oder Frameworks wie Inky zu nutzen, um responsive E-Mails zu generieren, die auch in Outlook perfekt aussehen.

Zudem – und das ist für Performance-Enthusiasten wichtig – blockiert der Mail-Versand den User nicht. Wenn du den Symfony Messenger (Message Queue) in Contao konfigurierst, wird $this->mailer->send() die Mail nur in eine Datenbank-Warteschlange legen. Der User sieht sofort die "Vielen Dank"-Meldung, während ein Hintergrund-Prozess (Worker) die Mail asynchron verschickt.

6. Best Practices für komplexe Formulare

Der komplette Lebenszyklus eines Symfony Forms in Contao

Du hast nun gesehen, wie mächtig Contao 5 Symfony Forms sind. Um deinen Code auch in großen Projekten wartbar zu halten, solltest du folgende Best Practices aus der Symfony-Welt verinnerlichen:

Übersetzungen (I18n) nutzen: Anstatt Labels hart in die BookingType.php zu schreiben ('label' => 'Ihr Name'), solltest du Translation-Keys verwenden ('label' => 'booking_form.customer_name'). Symfony übersetzt diese dann automatisch anhand deiner messages.de.yaml Dateien. Das macht dein Formular sofort mehrsprachig.
Data Transformers: Manchmal passt das Datenformat im HTML-Formular (z. B. ein String wie "01.08.2026") nicht zu dem, was deine Entity erwartet (z. B. ein Unix-Timestamp als Integer). Symfony bietet hierfür Data Transformers. Sie klinken sich zwischen das Formularfeld und die Entity ein und konvertieren die Daten in beide Richtungen transparent on-the-fly.
Form Types verschachteln (CollectionType): Will der Kunde mehrere Strandkörbe auf einmal buchen? Du kannst Formulare verschachteln! Ein BookingType kann eine Collection von BeachChairSelectionType Formularen enthalten. Symfony kümmert sich um das dynamische Hinzufügen (via JavaScript) und die Validierung der Arrays.

#formulare

Contao 5 Symfony Forms: Professionelle Formularverarbeitung