Zuletzt geändert am:
Zur Darstellung und Ausführung von Formularen benötigt Formcentric clientseitige Runtime-Dateien. Diese stellen die Formularlogik, Widget-Komponenten sowie Übersetzungen bereit.
Wie diese Dateien bereitgestellt und geladen werden, hängt von Ihrer gewählten Integrationsart ab:
Wählen Sie den für Ihr Setup zutreffenden Bereitstellungspfad.
Die aufgeteilte client.js ist ein kleines Einstiegsmodul, das client.core.js importiert. Die gemeinsame Runtime lädt Widgets aus components/ und Sprachen aus locales/. Veröffentlichen Sie beide Dateien und diese Verzeichnisse aus demselben Paket-Build mit unveränderter relativer Verzeichnisstruktur.
Die standardmäßige Einstiegs-URL /form/client.js darf weitergeleitet werden. Relative Imports werden anhand der endgültigen Antwort-URL aufgelöst. Einstieg und nachgeladene Widgets importieren anschließend dieselbe client.core.js; eine andere Einstiegs-URL erzeugt keine weitere gemeinsame Runtime-Instanz.
Bei Deployments unter einem Unterpfad kann eine Einstiegs-URL ohne Präfix in der Embed-Konfiguration bleiben, wenn der Server sie zum vollständigen Runtime-Verzeichnis unter dem Deployment-Präfix weiterleitet. Das Embed muss diese Weiterleitung des Einstiegs nicht umgehen.
Halten Sie die URLs der gemeinsamen Runtime und der Chunks konsistent. Werden nur einzelne Imports umgeschrieben oder wird die gemeinsame Runtime weitergeleitet, während Widgets sie über eine andere URL importieren, können doppelte Modulinstanzen entstehen. Veröffentlichen Sie für versionierte Deployments das vollständige Runtime-Verzeichnis unter einem Versionspräfix. Konfigurieren Sie bei stabilen URLs die Cache-Revalidierung für alle Runtime-Dateien.
| Hosting-Beispiel | Konfiguration |
| Eine Kundenwebsite bindet Formulare von einer anderen Delivery-Domain ein | Unterstützt, wenn Delivery ursprungsübergreifende Modul-Anfragen für Einstieg, gemeinsame Runtime und verschachtelte Chunks erlaubt. Der Hostname der Website verändert die relativen Modul-URLs nicht. |
Ein CDN leitet /client/latest/client.js auf /client/v42/client.js weiter |
Unterstützt. Veröffentlichen Sie client.core.js, components/ und locales/ neben der endgültigen Einstiegs-URL unter /client/v42/. |
| Ein Reverse Proxy ordnet einem öffentlichen Präfix gespeicherte Assets zu | Stellen Sie unter diesem Präfix die vollständige Verzeichnisstruktur bereit. Interne Rewrites erhalten die öffentlichen URLs. Weiterleitungen des Einstiegs werden unterstützt, wenn am endgültigen Ort das vollständige Runtime-Verzeichnis liegt. |
formapp.js ist der vollständig gebündelte UMD-Kompatibilitätseinstieg für bestehende Integrationen. Die Datei enthält alle mitgelieferten Widgets und Sprachen und benötigt keine Runtime-Chunk-Verzeichnisse. Ältere Wrapper laden diese Datei weiterhin als klassisches Skript.
Der Wrapper wählt die Runtime wie folgt:
formappUrl lädt der Wrapper /form/client.js von der Base URL mit type="module". Modul-Anfragen benötigen bei einem anderen Ursprung CORS sowie einen JavaScript-Content-Type. Sie senden standardmäßig keine ursprungsübergreifenden Zugangsdaten.formappUrl / data-fc-formapp-url wählt die vollständige klassische formapp.js und wird immer als klassisches Skript geladen, auch bei nicht sprechenden CMS-Medien-URLs. Diese Option darf nicht auf ein ES-Modul zeigen.formappUrl ist für neue Cloud-Integrationen deprecated; ohne diese Angabe wird die standardmäßige aufgeteilte Runtime verwendet. Bestehende klassische Einbindungen bleiben unterstützt.Das Client-SDK (@formcentric/client) sowie die React- und Vue-Pakete enthalten jeweils die Formular-Runtime und importieren sie beim Einbinden eines Formulars dynamisch. Sie laden client.js nicht von Delivery und akzeptieren formappUrl nicht. Der Bundler der konsumierenden Anwendung verarbeitet die enthaltene Runtime und ihre Widget- und Sprach-Imports und erzeugt eigene Chunk-Namen und Referenzen. Die React- und Vue-Pakete benötigen das Client-Paket nur für dessen Theme-Assets.
Veröffentlichen Sie den vollständigen Anwendungs-Build einschließlich aller erzeugten Chunks. Konfigurieren Sie die Asset-Basis-URL beziehungsweise den Public Path des Bundlers für das Deployment-Verzeichnis oder CDN. Laden Sie neben der gebündelten Runtime keine weitere unverarbeitete Runtime separat. Wird die Runtime vom Bundling ausgeschlossen und unverändert ausgeliefert, gelten die Anforderungen für die direkte Auslieferung oben.
