Background Decoration
27.7.2026Dietrich Bojko13 Min. Lesezeit

Module & Formulare im Frontend rendern

Zurück zur Übersicht
Module & Formulare im Frontend rendern
Bild mit KI generiert.
Bild mit KI generiert.
15 Views

Häufig gestellte Fragen (FAQ)

Contao liefert ja den Formulargenerator mit.
In der Theorie klingt es verlockend, einen FormRenderer zu schreiben, der über das Array der Formularfelder loopt und dynamisch <input>-Tags generiert. In der Praxis (und in Enterprise-Projekten) stößt du damit jedoch sehr schnell an Grenzen. Komplexe mehrstufige Formulare (Multi-Step), asynchrone Validierungen (z.B. "Ist die E-Mail schon vergeben?") oder hochspezifische UX-Patterns lassen sich mit dynamischen Generatoren kaum abbilden. Der "Bespoke"-Ansatz (spezifische React-Komponenten für spezifische Formulare) ist wartbarer, typsicherer und bietet eine drastisch bessere User Experience.

Reicht nicht eines?
Nein. Die Backend-Validierung (Symfony) ist für die Sicherheit zuständig (um bösartige Payloads abzuwehren, die die UI umgehen). Die Frontend-Validierung (Zod) ist für die User Experience zuständig (um dem Nutzer sofort Feedback zu geben, ohne auf eine Server-Antwort warten zu müssen). Das ist das Prinzip der Defense in Depth.

Ja. Wenn du in Contao ein völlig neuartiges Element baust (z. B. einen interaktiven 3D-Viewer), musst du im Next.js-Frontend die entsprechende React-Komponente (ViewerBlock.tsx) schreiben und sie im BlockRenderer (der componentMap) registrieren. Das ist der Architektur-Kompromiss, den man bei entkoppelten Systemen eingeht.

Dateiuploads erfordern, dass du in deiner Next.js Server Action die FormData API verwendest (anstatt application/​json). Du nimmst das File-Objekt aus dem Client entgegen und sendest es als multipart/​form-data an den Contao-Controller, den wir in Teil 6 genau für diesen Zweck (mit Dbafs::addResource()) präpariert haben.

Dein nächster Schritt: Der Draft- und Preview-Modus

Unsere Architektur steht, die Seite lädt in Millisekunden und die Formulare sind sicher. Doch eine entscheidende Frage aus der Redakteurs-Perspektive ist noch offen:
"Wie kann ich meine Änderungen sehen, bevor ich sie veröffentliche?"

In der monolithischen Welt klickt der Redakteur in Contao einfach auf das kleine "Auge"-Icon und sieht die unveröffentlichte Seite. Im Headless-Setup beißt sich dieser Wunsch massiv mit unserer Next.js Caching-Architektur (ISR). Wenn Next.js die Seiten statisch generiert, wie können wir dem Redakteur im Contao-Backend eine Live-Vorschau seiner Änderungen bieten, ohne den Cache für reguläre Besucher zu zerstören?

Im kommenden Teil 10: Der Draft-/Preview-Modus lösen wir dieses komplexe Problem. Du wirst lernen:

  • Das Next.js Draft Mode API: Wie wir den statischen Cache gezielt und sicher für einzelne User (Redakteure) umgehen.

  • Die Contao Backend-Integration: Wie wir das Next.js-Frontend als iframe-Vorschau direkt in das Contao Backend injizieren.

  • Token-basierte Authentifizierung: Wie das Frontend erkennt, dass gerade ein berechtigter Contao-Redakteur auf die Seite zugreift.

Jetzt starten: Teil 10 – Der Draft-/Preview-Modus für Redakteure einrichten

Dietrich Bojko
Über den Autor

Dietrich Bojko

Senior Webentwickler

Webinteger arbeitet seit vielen Jahren produktiv mit Linux-basierten Entwicklungsumgebungen unter Windows.
Der Fokus liegt auf performanten Setups mit WSL 2, Docker, PHP, Node.js und modernen Build-Tools in realen Projekten – nicht auf theoretischen Beispielkonfigurationen.

Die Artikel dieser Serie entstehen direkt aus dem täglichen Einsatz in Kunden- und Eigenprojekten und dokumentieren bewusst auch typische Fehler, Engpässe und bewährte Workarounds.

Webseite besuchen

Das könnte Sie auch interessieren

Schreiben Sie einen Kommentar