Formular-Entwicklerdokumentation

Formulare sind zentral verwaltete Einsendungsmodelle, die in FaceFlow-Seiten und -Komponenten eingebettet werden.

Sie ermöglichen es technischen Teams, wiederverwendbare Anfrage- und Intake-Workflows zu definieren, die cache-sicher gerendert, zur Einsendezeit verarbeitet und als strukturierte Geschäftsassets verwaltet werden können.

Kernverantwortung

Ein Formular ist verantwortlich für:

• wiederverwendbare Formulardefinitionen
• Feldschema
• Laufzeitrendering
• Validierungs- und Einsendeverarbeitung
• Weiterleitung von Benachrichtigungen
• Erfassung von Einträgen
• Wiederverwendung über mehrere Seiten oder Komponenten hinweg

Ein Formular sollte einen Geschäftsablauf klar modellieren. Wenn eine Definition versucht, mehrere nicht zusammenhängende Workflows abzudecken, werden sowohl der Betrieb als auch das Reporting schwächer.

Kernmodell des Formulars

Ein Formular kombiniert normalerweise:

• eine stabile Formularidentität
• ein Feldschema
• Präsentationskonfiguration
• Erfolgs- und Benachrichtigungsverhalten
• Regeln zur Verarbeitung von Einsendungen
• Speicherung und Verwaltung von Einträgen

In der Praxis definiert die Formularebene sowohl, was der Besucher einsenden kann, als auch wie das Unternehmen diese Einsendung empfängt und verarbeitet.

Konzeptionell:

{
  "name": "enterprise-demo-request",
  "fields": [
    { "name": "full_name", "type": "text", "required": true },
    { "name": "work_email", "type": "email", "required": true },
    { "name": "company", "type": "text", "required": true },
    { "name": "message", "type": "textarea", "required": false }
  ],
  "settings": {
    "submitText": "Request demo",
    "successMessage": "Thanks. Our team will contact you shortly."
  }
}

Unterstützte Feldtypen

Unterstützte Feldtypen umfassen:

• text
• email
• phone
• url
• textarea
• number
• select
• radio
• checkbox
• checkboxes
• date
• file
• hidden

Feldsets sollten mit dem operativen Workflow übereinstimmen. Ein Formular, das Daten sammelt, die das Geschäft nicht nutzt, erzeugt Reibung für Besucher und interne Teams gleichermaßen.

Beispiel für die Formulardefinition

Eine technische Überprüfung sollte in der Lage sein, das Modell schnell nachzuvollziehen:

{
  "name": "contact-sales",
  "fields": [
    { "name": "full_name", "type": "text", "required": true },
    { "name": "work_email", "type": "email", "required": true },
    { "name": "company", "type": "text", "required": true },
    { "name": "team_size", "type": "select", "required": false }
  ],
  "settings": {
    "submitText": "Contact sales",
    "successMessage": "Thank you. We will reply shortly."
  }
}

So lässt sich vor der Einbettung auf einer Seite über Feldvertrag, erforderliche Daten und Workflow-Eigentümerschaft sprechen.

Einbettung zur Laufzeit

Formulare werden typischerweise über Komponenten in Seitenabschnitte eingebettet.

Ein gängiges Einbettungsmarker ist:

<div data-form-embed="contact-form"></div>

Beispielabschnitt:

<section class="contact-section">
  <div class="section-copy">
    <h2>Talk to our team</h2>
    <p>Tell us about your goals and timeline.</p>
  </div>

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

Das ermöglicht es, die Seitenstruktur wiederverwendbar zu halten, während das eigentliche Formularmodell zentral verwaltet bleibt.

Feste vs. feldgestützte Einbettungen

Es gibt zwei gängige Einbettungsmuster.

Verwenden Sie eine feste verwaltete Formular-ID, wenn die Vorlage immer genau ein bestimmtes Formular rendern soll:

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

Verwenden Sie eine feldgestützte Einbettung, wenn eine Komponente ein formSelect-Feld bereitstellt und Autoren das verwaltete Formular zur Autoring-Zeit auswählen sollen:

<div data-form-embed="{contactForm}"></div>

Entscheidungsregel:

• fixed embed -> one stable workflow owned by the template
• field-backed embed -> reusable Component with author-selectable workflow

Ablauf der Einsendung

Auf hoher Ebene:

1. das Formular wird zentral definiert
2. es wird über eine Komponente in eine Seite eingebettet
3. der Besucher sendet strukturierte Eingaben
4. Validierung und Einsendeverarbeitung laufen
5. die Einsendung wird gespeichert und an den relevanten Geschäftsworkflow weitergeleitet

Konzeptionell:

Component render
  -> runtime form HTML
  -> visitor submits
  -> validation
  -> entry saved
  -> notification routed
  -> success response returned

Integrationsmuster

Der saubere Integrationspfad ist:

Form definition
-> Component embed via formSelect or explicit data-form-embed marker
-> Page composition
-> runtime rendering and submission handling

Das hält das Formularverhalten zentralisiert, während Seiten und Komponenten wiederverwendbar bleiben.

Benachrichtigungen und Einträge

Formulare betreffen nicht nur die Frontend-Erfassung. Sie unterstützen auch die operative Seite der Einsendungen.

Typische Fähigkeiten umfassen:

• Weiterleitung von Benachrichtigungen
• Verwaltung von Einsendeeinträgen
• Überprüfung von Einträgen
• Export-Workflows

Technische Teams sollten den vollständigen operativen Pfad überprüfen, nicht nur, ob das Formular visuell auf der Seite gerendert wird.

Richtlinien zum Feldvertrag

Halten Sie den Feldvertrag eng genug, damit der Workflow offensichtlich bleibt.

Typische Muster:

• Kontakt- oder Demoanfrage -> text, email, textarea, optional select
• Qualifizierungs-Flow -> text, email, select, number
• Upload-gestütztes Intake -> file nur hinzufügen, wenn das Unternehmen Anlagen tatsächlich verarbeitet

Bevorzugen Sie einen klaren Workflowvertrag gegenüber einem übergroßen Formular, das versucht, jeden möglichen Lead-Pfad zu erfassen.

Wiederverwendungsstrategie

Gutes Formular-Design bevorzugt in der Regel Wiederverwendung.

Wenn mehrere Seiten denselben Geschäftsworkflow teilen, sollten sie in der Regel dasselbe Formularmodell verwenden.

Das verbessert:

• Wartbarkeit
• Konsistenz der Feldverträge
• Benachrichtigungsverhalten
• Reporting und nachgelagerte Verarbeitung

Beispiel:

Homepage demo CTA
Pricing page demo CTA
Enterprise solution page CTA
  -> same demo-request Form

Wenn der Workflow derselbe ist, sollte in der Regel auch das Formular dasselbe sein.

Technische Hinweise

• modellieren Sie jedes Formular um einen Geschäftsworkflow
• verwenden Sie eine Formulardefinition wieder über Seiten hinweg, wenn der Workflow derselbe ist
• halten Sie die Feldanforderungen an den tatsächlichen betrieblichen Bedarf angepasst
• vermeiden Sie seiten-spezifische Duplikation, wenn ein gemeinsames Modell funktioniert
• überprüfen Sie Rendering, Einsendung, Benachrichtigung und Eintragsverarbeitung gemeinsam
• testen Sie den echten Einsendeweg vor der Freigabe

Fehlmuster

Vermeiden Sie:

• für jede Seite ein neues Formular zu erstellen, wenn der Workflow identisch ist
• nicht zusammenhängende Lead-Pfade in einem übergroßen Formular zu kombinieren
• optionale Daten zu sammeln, die das Unternehmen nie nutzt
• Formular-Markup fest in Seitentemplates zu codieren anstatt das verwaltete Modell einzubetten
• nur die visuelle Ausgabe zu prüfen und den operativen Pfad zu ignorieren

Beispielaufbau

Component:
  lead-form

Embed:
  <div data-form-embed="contact-sales"></div>

Pages:
  /pricing/
  /enterprise/
  /contact/

Das hält einen Workflow über mehrere Conversion-Flächen hinweg konsistent.

Verwandte

• Produktübersicht zu Formularen
• Formularanleitung
• Komponenten
• Seiten
• Export und Import