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.
0 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