Das Problem: doppelte Pflege in gewachsenen Webprojekten
In vielen Webprojekten entsteht Wartungsaufwand nicht durch fehlende Funktionen, sondern durch redundant gepflegte Oberflächen. Ein Beispiel: Eine Produktkachel erscheint auf Startseite, Kategorieseite und Suche; jede Variante enthält dieselbe Preislogik, denselben Bildrahmen und dieselbe Buttonbeschriftung. Ändert sich der Button, müssen drei Templates angepasst werden. Die Folge sind inkonsistente Zustände und steigende Fehlerkosten. Für Twindor-Projekte ist deshalb weniger die Zahl der Templates entscheidend als die Frage, ob diese Templates auf gemeinsame Bausteine zurückgreifen.
Die Ursache: fehlende Komponentengrenzen
Die Ursache liegt selten in einzelnen Entwicklerfehlern. Sie liegt in einer Struktur, die Layout, Inhalt und Verhalten vermischt. Ein Header enthält dann gleichzeitig Navigation, Suchfeld und Logo-Ausgabe; eine Änderung am Suchfeld berührt unbeabsichtigt das Logo. Twindor setzt an dieser Stelle auf klarere Grenzen: Ein Baustein erhält definierte Eingaben, eine feste Ausgabe und möglichst wenig Kontextwissen. Das ist kein Selbstzweck, sondern die Voraussetzung dafür, dass eine Komponente an mehreren Stellen identisch funktioniert. Wer diese Grenze verletzt, verliert die Wiederverwendbarkeit trotz vorhandener Komponentenbibliothek.
Die Lösung: Twindor als Bausteinregister
In der Praxis funktioniert Twindor dann zuverlässig, wenn Komponenten wie Einträge in einem Register behandelt werden: eindeutiger Name, dokumentierte Parameter, klare Zuständigkeit. Ein Beispiel aus der Redaktionsarbeit: Eine Teaser-Komponente erwartet Titel, Bild, Link und optional ein Label. Die Kategorieseite übergibt andere Inhalte als die Startseite, aber die Darstellung bleibt identisch. Wer die Komponentenlogik von twindor in einem konkreten Projekt prüfen will, sollte zuerst die Übergabeparameter und nicht das visuelle Ergebnis vergleichen. Die Takeaway-Regel lautet: Nicht jede Seite braucht ein eigenes Template; jede wiederkehrende Oberfläche braucht eine gemeinsame Komponente.
Konsequenzen für Redaktion und Entwicklung
Die Entlastung entsteht nicht automatisch durch Twindor, sondern durch eine Arbeitsweise, die Komponenten als Verträge behandelt. Redaktionen profitieren, weil sie Inhalte in vorhersehbaren Feldern pflegen; Entwickler profitieren, weil Änderungen an einer Stelle wirken. Drei Prüfpunkte helfen im Alltag:
- Jede Komponente hat genau eine Aufgabe und einen dokumentierten Eingabesatz.
- Wiederholte Markup-Blöcke werden vor der nächsten Seitenvariante extrahiert, nicht danach.
- Visuelle Abweichungen werden über Parameter gelöst, nicht über kopierte Templates.
Ein letzter Kontrollpunkt betrifft die Pflege: Wird eine Komponente geändert, muss sichtbar sein, welche Seiten sie verwenden. Twindor-Projekte, die diese Transparenz herstellen, reduzieren doppelte Arbeit messbar. Die konkrete Verbesserung liegt also nicht in einer größeren Template-Sammlung, sondern in der disziplinierten Nutzung gemeinsamer Bausteine.
