Content-Plattform für eingebettete Produktkomponenten

Wer eine Anwendung baut, besitzt die Seite, in der sie läuft. Hier war das nicht so. Die Komponenten waren dafür gedacht, in eine bestehende Webpräsenz eingesetzt zu werden, deren Aufbau, Stylesheets und Ladeverhalten von woanders kamen und sich ändern konnten, ohne zu fragen.

Das dreht die üblichen Annahmen um. Eine Komponente darf keine globalen Stile setzen und sich auf keine verlassen. Sie muss ihre eigenen Zustände mitbringen, weil es keinen Anwendungsrahmen gibt, der sie hält. Sie muss auf einem Gerät funktionieren, dessen Breite sie nicht kennt, in einem Dokument, dessen Rest ihr nicht gehört.

Was hier also gebaut wurde, sind keine Seiten und keine Anwendung, sondern in sich geschlossene Bausteine mit eigener Logik, eigener Darstellung und eigener Datenhaltung — jeder für sich lauffähig, ohne Voraussetzungen an seine Umgebung.

Zwischen einem fertigen Baustein und einem Baustein, der in einer fremden Seite erscheint, liegt ein eigener Weg. Er entscheidet darüber, was eine Inhaltsänderung kostet — und genau dieser Weg hat sich über die Jahre am stärksten verändert.

Am Anfang war er kurz und vollständig manuell: Wer den Inhalt ändern wollte, änderte die Datei. Am Ende steht derselbe Weg, aber ohne Handarbeit im mittleren Teil — der Inhalt liegt in einem Datenbestand, die Auslieferung entsteht daraus.

Wichtig ist dabei, was sich nicht geändert hat. Aus Sicht der einbettenden Seite bleibt es ein einziger Einbindungspunkt. Die Zentralisierung verändert die Pflege, nicht die Schnittstelle nach außen — sonst würde jeder Schritt eine Abstimmung mit fremden Seiten erfordern.

Die zweite größere Komponente ist ein Rechner, und sein Reiz liegt in einer Beobachtung: Eine amtliche Teuerungsrate beschreibt einen Durchschnittshaushalt. Fast niemand ist dieser Haushalt. Wer wenig fährt und viel heizt, erlebt eine andere Rate als die veröffentlichte — nicht weil die Zahl falsch wäre, sondern weil sie nach einem fremden Warenkorb gewichtet ist.

Der Rechner nimmt deshalb dieselben amtlichen Indexreihen, rund zwanzig an der Zahl, und gewichtet sie neu: nach den Ausgaben, die jemand selbst angibt. Für jeden Monat der Reihe entsteht so ein persönlicher Indexwert als gewichtetes Mittel über die Kategorien; die Jahresrate ergibt sich aus dem Vergleich mit dem Wert zwölf Monate zuvor. Dargestellt werden beide Verläufe nebeneinander — der eigene und der amtliche.

Der Aufwand steckt weniger in der Formel als in allem darum herum: Ausgabenwerte müssen in einer Form eingegeben werden können, in der Menschen über Geld denken, unvollständige Eingaben dürfen kein Ergebnis erzwingen, und die Kategorien brauchen eine Voreinstellung, damit der Rechner auch dann etwas zeigt, wenn jemand nur eine einzige Zahl eingetragen hat.

Die Antwort darauf war keine weitere Komponente, sondern eine Ebene darunter: eine serverseitige Anwendung, in der Produktangaben und komponentenbezogene Inhalte als Daten liegen statt als Quelltext.

Das Modell ist bewusst klein gehalten. Es gibt einen schlanken Produktdatensatz mit den Angaben, die überall gebraucht werden. Es gibt je Komponente einen Satz benannter Feldwerte. Und es gibt eine deklarative Angabe darüber, welche Felder ein Komponententyp überhaupt kennt — damit ein neuer Typ eine Konfigurationsfrage bleibt und keine Modelländerung wird. Über all dem liegt eine Redaktionsoberfläche mit Anmeldung und Rollenbeschränkung.

Ausgeliefert wird serverseitig gerendert. Ein Endpunkt zeigt die Vorschau, ein zweiter gibt dieselbe Komponente als JavaScript aus. Damit ist die Trennung sauber: Inhalt ist Datenbestand, Darstellung ist Vorlage, Auslieferung ist ein Aufruf. Was vorher eine Änderung an einer Datei war, ist danach eine Änderung an einem Datensatz — und wirkt an allen Stellen, die diesen Datensatz verwenden.

Rückblickend ist der interessante Teil dieses Falls nicht die einzelne Komponente, sondern der Übergang.

Für eine Handvoll Bausteine ist eine eigene Verwaltungsebene überzogen — sie kostet mehr, als sie spart, und niemand hätte sie zu Beginn bauen sollen. Für mehrere Komponenten mit gemeinsamen Produktangaben und laufender inhaltlicher Pflege kippt diese Rechnung. Der richtige Zeitpunkt für die Zentralisierung war deshalb weder am Anfang noch, als es unerträglich wurde, sondern an der Stelle dazwischen, an der die Wiederholung sichtbar und der Umbau noch überschaubar war.

Was den Umbau möglich gemacht hat, war eine Eigenschaft der ersten Lösung: Jede Komponente war von Beginn an in sich geschlossen und hatte genau einen Einbindungspunkt nach außen. Genau diese Eigenschaft macht es möglich, hinter dem Einbindungspunkt die Herkunft des Inhalts auszutauschen, ohne die Schnittstelle nach außen zu ändern. Bausteine sauber zu schneiden zahlt sich selten sofort aus. Es zahlt sich an dem Tag aus, an dem man sie anders zusammensetzen will.