Seiten-Entwicklerdokumentation

Seiten sind die oberste Zusammenstellungseinheit in FaceFlow.

Für technische Anwender ist eine Seite keine Template-Datei. Sie ist ein strukturiertes Laufzeit‑Datensatz, das ein Layout, geordnete Abschnitte, gemeinsame Assets und optionale Geschäftssysteme zu einem veröffentlichbaren Erlebnis verbindet.

Kernverantwortung

Die Ebene der Seite ist verantwortlich für:

die Auswahl der Layout-Hülle
das Speichern der geordneten Abschnittszusammensetzung
das Verknüpfen verfasster Feldwerte mit wiederverwendbaren Komponentenverträgen
das Koordinieren eingebetteter Systeme wie Formulare, Bewertungen und Listen
die Unterstützung gesteuerter Bearbeitungs-, Vorschau- und Veröffentlichungsabläufe

Seiten sollen orchestrieren. Sie sollten nicht der Ort werden, an dem Layout‑Logik, Entscheidungen zum Komponenten‑Schema und einmalige Geschäftsregeln alle zusammenfließen.

Seitenmodell

Eine typische Seite kombiniert:

ein Layout
eine geordnete Liste von Komponenteninstanzen
optional wiederverwendbare, seitenweit gültige Abschnitte
optional eingebettete Formular‑ oder Bewertungs‑Erfahrungen
optional dynamisches Listenverhalten

Konzeptionell:

{
  "layout": "default-site",
  "components": [
    {
      "component": "hero-banner",
      "scope": "page",
      "fields": {
        "heading": "Build faster with FaceFlow",
        "subheading": "Reusable sections for scalable websites"
      }
    },
    {
      "component": "testimonial-strip",
      "scope": "layout"
    }
  ]
}

Die genaue Speicherimplementierung ist intern. Entscheidend für technische Anwender ist der Vertrag: Seiten setzen wiederverwendbare Objekte zusammen, anstatt direkt rohen Template‑Code zu besitzen.

Render-Pfad

Zur Laufzeit folgt das Rendering einer Seite typischerweise diesem Ablauf:

die angeforderte Seite auflösen
das zugewiesene Layout laden
gemeinsame site-, layout- und seitenweite Abschnitte auflösen
geordnete Komponenten mit ihren Feldwerten rendern
eingebettete dynamische Systeme wie Listen, Formulare oder Bewertungen rendern
die final zusammengebaute Ausgabe zurückgeben

Eine vereinfachte Struktur sieht so aus:

<body>
  {header}
  {siteComponents}
  <main>
    {content}
  </main>
  {footer}
</body>

Die Seite besitzt die Orchestrierung von {content}. Das Layout besitzt die Hülle darum herum.

Aufbaubeispiel

Ein expliziterer Seitenaufbau lässt sich so darstellen:

{
  "layout": "service-site-shell",
  "components": [
    {
      "component": "hero-banner",
      "scope": "page",
      "fields": {
        "heading": "Enterprise Security",
        "summary": "Structured trust content for SaaS websites",
        "ctaUrl": "/contact/"
      }
    },
    {
      "component": "lead-form",
      "scope": "page",
      "fields": {
        "contactForm": "contact-sales"
      }
    }
  ]
}

Dieses Beispiel ist nützlich, weil es zeigt, dass die Seite Komposition und Instanzwerte besitzt, während Layout‑ und Komponentenverträge getrennt bleiben.

Beziehung zu Layouts und Komponenten

Behalten Sie diese Grenzen strikt:

Layout definiert die Seitenhülle
Komponente definiert einen Vertrag für wiederverwendbare Abschnitte
Seite setzt eine Sequenz von Komponenten zu einem finalen Erlebnis zusammen

Wenn eine Seite beginnt, strukturelle Shell‑Logik zu tragen, ist das Layout zu schwach.

Wenn eine Seite beginnt, Abschnittsregeln zu duplizieren, die einer Komponente gehören sollten, bricht die Wiederverwendbarkeit zusammen.

Beispiel für eine typische Seitenkomposition

default-site layout
  -> hero-banner component
  -> feature-grid component
  -> lead-form component
  -> faq-accordion component

Diese Komposition sollte verständlich bleiben, ohne benutzerdefinierten Code zu lesen. Wenn das nicht der Fall ist, driftet die Architektur in der Regel.

Dynamische und interaktive Inhalte

Seiten enthalten oft mehr als statische Abschnitte. Häufige Fälle sind:

eine Lead‑Erfassungs‑Komponente, die ein Formular einbettet
ein Vertrauensabschnitt, der ein Bewertungsmodell einbettet
ein Ressourcenarchiv, das von einer Liste gesteuert wird
seitenbezogene Variablen, die in mehreren Abschnitten wiederverwendet werden

Beispiel:

<section class="section-contact">
  <div data-form-embed="enterprise-demo-request"></div>
</section>

<section class="section-proof">
  <div data-review-embed="customer-success-reviews"></div>
</section>

Deshalb sollte die Seiten‑Design‑Prüfung den vollständigen Laufzeitpfad berücksichtigen, nicht nur die visuelle Komposition.

Integrationsgrenzen

Bei der technischen Überprüfung sollten diese Grenzen stabil bleiben:

Die Seite wählt, welche wiederverwendbaren Systeme am Erlebnis teilnehmen
Die Komponente definiert, wie ein wiederverwendbarer Abschnitt gerendert wird
Form‑ und Bewertungsmodelle besitzen das Einreichungsverhalten
Listendefinitionen besitzen das dynamische Archivverhalten

Wenn eine Seite zu viele Implementierungsdetails trägt, driftet das Objektmodell.

Seitentypen und Änderungsstrategie

Nicht jede Seite sollte gleich behandelt werden.

Kampagnenseiten optimieren für Geschwindigkeit und kontrollierte Variation
dauerhafte Service‑Seiten optimieren für Wiederverwendbarkeit und langfristige Wartung
listengetriebene Seiten optimieren für dynamisches Inhaltswachstum
Vertrauens‑ oder Conversion‑Seiten koordinieren oft mehrere Systeme zusammen

Technische Teams sollten die passenden umgebenden Assets für jeden Typ wählen, anstatt jede Seite in dasselbe Muster zu pressen.

Versionierung, Lokalisierung und Portabilität

Seiten sind oft die Einheit, mit der Teams:

über Sprachen hinweg lokalisieren
nach einer unerwünschten Änderung wiederherstellen
zwischen Umgebungen verschieben
vor der Veröffentlichung prüfen

Behandeln Sie die Seite als operatives Asset, nicht nur als visuelles Ausgabenziel.

Verwandte Funktionsreferenzen:

Technische Prüfliste

Verwendet die Seite das korrekte Layout für ihre Seitenfamilie?
Sind Komponenten in der beabsichtigten Reihenfolge und mit dem richtigen Geltungsbereich (scope) angeordnet?
Werden Formulare, Bewertungen oder Listen über wiederverwendbare Verträge eingebettet statt mit hartcodiertem Markup?
Vertraut die Seite auf Variablen oder gemeinsame Abschnitte, wo Wiederverwendung erwartet wird?
Würde ein zukünftiger Redakteur die Seitenstruktur verstehen, ohne Ausnahmen rückentwickeln zu müssen?

Anti‑Pattern

Vermeiden Sie diese Muster:

seitenspezifisches Shell‑Markup, das im Layout liegen sollte
freiform‑Abschnittsmarkup, das sich über viele Seiten wiederholt
Geschäftslogik, die im seiten‑einzigen Inhalt versteckt ist
das Vermischen unzusammenhängender Ziele in einer Seite, nur weil sie bereits live ist
ein dynamisches Archiv in eine manuell gepflegte Seitenkomposition zu pressen

Beispiel-Aufbaumuster

Für eine typische Service‑Landingpage:

Layout: service-site-shell
Page:
  - hero-banner
  - benefits-grid
  - customer-logos
  - review-strip
  - demo-request-form

Dieses Muster bleibt wartbar, weil jede Verantwortung ein klares Zuhause hat.