FaceFlow Entwicklerübersicht
FaceFlow Entwicklerübersicht
FaceFlow ist der strukturierte No-Code-Baukern innerhalb von PageFace.
Aus technischer Sicht lässt es sich am besten als ein System wiederverwendbarer Objekte, gesteuerten Renderings und klarer Zuständigkeitsgrenzen verstehen, und nicht als ein freiformiger Seiteneditor.
Das Kerntechnische Modell
FaceFlow besteht aus einer kleinen Menge von Objekttypen mit unterschiedlichen Verantwortlichkeiten:
- Variables für leichtgewichtige wiederverwendbare Fragmente
- Components für wiederverwendbare Abschnittsverträge
- Layouts für gemeinsame Seitenhüllen
- Pages für zusammengefügte Erlebnisse
- Lists für dynamische, sammlungsgetriebene Ausgaben
- Forms für strukturierte Einreichungs-Workflows
- Reviews für moderierte Vertrauensinhalte
Jedes Objekt existiert, um eine andere Ebene des Webseitensystems zu lösen. Wenn diese Grenzen klar bleiben, bleibt FaceFlow auch bei großem Umfang wartbar.
Wie man über FaceFlow denkt
Das sauberste mentale Modell ist:
Variables -> small reusable fragments
Components -> reusable sections
Layouts -> page shells
Pages -> assembled experiences
Lists -> dynamic archives and collections
Forms -> lead and request workflows
Reviews -> trust and proof workflowsDas ist nicht nur eine Inhalts-Hierarchie. Es ist eine Architektur-Hierarchie.
Objektgrenzen
Verwenden Sie dieses Entscheidungsmodell:
- verwenden Sie eine Variable, wenn die Wiederverwendungseinheit klein und parameterisiert ist
- verwenden Sie eine Component, wenn die Wiederverwendungseinheit ein kompletter Abschnitt mit einem editororientierten Schema ist
- verwenden Sie ein Layout, wenn die Sorge der Seitenrahmen um viele Pages herum gilt
- verwenden Sie eine Page, wenn Sie eine finale Route oder ein Erlebnis zusammenstellen
- verwenden Sie eine List, wenn Inhaltsauswahl und Pagination Teil des Vertrags sind
- verwenden Sie ein Form, wenn Sie strukturierte Einreichungen sammeln
- verwenden Sie ein Review, wenn Sie geregeltes öffentliches Feedback sammeln und veröffentlichen
Die meisten technischen Abweichungen in FaceFlow entstehen, wenn ein Objekt beginnt, Verantwortung für ein anderes zu übernehmen.
Beispielssystem
Layout:
default-site-shell
Page:
/enterprise/
Components:
hero-banner
benefits-grid
demo-request-section
review-strip
Embedded systems:
<div data-form-embed="enterprise-demo-request"></div>
<div data-review-embed="customer-success-reviews"></div>
Variables:
[[site-announcement]]
[[sales-contact-badge]]Dieses Beispiel bleibt wartbar, weil jeder Verantwortungsbereich einen klaren Ort hat.
Geltungsbereich und Auswirkungen von Änderungen
Der Geltungsbereich ist eines der wichtigsten technischen Konzepte in FaceFlow.
Er steuert, ob ein wiederverwendbarer Abschnitt sich verhält wie:
- ein websiteweites Asset
- ein Asset für eine Layout-Familie
- ein seitenlokales Asset
Wenn technische Anwender den falschen Geltungsbereich wählen, werden Auswirkungen von Änderungen schwer vorhersehbar. Ein lokaler Abschnitt kann versehentlich zu einer globalen Abhängigkeit werden, oder wiederholte Seiteninhalte können lange dupliziert bleiben, nachdem sie hätten geteilt werden sollen.
Vorlagenebene
FaceFlow-Vorlagen werden mit Facet erstellt.
Das bedeutet, technische Anwender sollten verstehen:
- Feldausgabe
- Bedingungen
- Schleifen
- Filter
- Einbetten von Variablen
- sichere Abschnittszusammensetzung
Beispiel:
<section class="hero">
<h1>{{ title }}</h1>
{{#if summary}}
<p>{{ summary }}</p>
{{/if}}
[[sales-contact-badge]]
</section>Facet ist die Vorlagenebene. FaceFlow ist das strukturierte Objektsystem darum herum.
Worauf sich technische Anwender konzentrieren sollten
Beim Entwerfen mit FaceFlow sind die wichtigsten technischen Entscheidungen in der Regel:
- wo Wiederverwendung hingehört
- wie viel Schema ein Abschnitt offenlegen sollte
- ob etwas dynamisch oder statisch sein sollte
- wie groß der tatsächliche Änderungsradius eines geteilten Assets ist
- wie viel der Seite in Layout versus Component versus Page-Komposition gehört
Diese Entscheidungen haben mehr Einfluss auf die Wartbarkeit als irgendein einzelner Seiteninhalt.
Häufige technische Fehler
Vermeiden Sie diese Muster:
- Components verwenden, wo Variables klarer wären
- Variables verwenden, wo ein echtes Abschnittsschema benötigt wird
- seiten-spezifische Inhalte ins Layout schieben
- eine übergroße Component erstellen, die versucht, viele unzusammenhängende Anwendungsfälle zu lösen
- Lists wie ein Auffangbecken für unklare Inhaltsarchitektur behandeln
- Geschäfts-Workflows einbetten, ohne den gesamten Render- und Moderationspfad zu überprüfen
Empfohlene Lesereihenfolge
Dieser Pfad führt von den kleinsten wiederverwendbaren Einheiten zur vollständigen Webseiten-Zusammenstellung und anschließend in die Vorlagenebene.