Architektur von HTML5-Formularen architecture-of-html-forms

Architektur architecture

Die HTML5-Formularfunktionen werden als Paket innerhalb der eingebetteten AEM-Instanz bereitgestellt. Die Bereitstellung erfolgt mithilfe einer REST-konformen Apache Sling Architecture als REST-Endpunkt über HTTP/S.

02-aem-forms-architecture_large

Über das Sling Framework using-sling-framework

Apache Sling ist ressourcenzentriert. Es verwendet eine Anfrage-URL, um die Ressource zuerst aufzulösen. Jede Ressource verfügt über die Eigenschaft sling:resourceType (oder sling:resourceSuperType). Basierend auf dieser Eigenschaft, der Anfragemethode und den Eigenschaften der Anfrage-URL wird dann ein Sling-Skript ausgewählt, um die Anfrage zu verarbeiten. Dieses Sling-Skript kann ein JSP oder ein Servlet sein. Im Falle von HTML5-Formulare dienen Profil-Knoten als Sling-Ressourcen, und der Profil-Renderer dient als Sling-Skript, das die Anforderung bearbeitet, das mobile Formular mit einem bestimmten Profil zu rendern. Ein Profil-Renderer ist ein JSP, das Parameter aus einer Anforderung ausliest und den Forms OSGi-Dienst aufruft.

Weitere Informationen über REST-Endpunkte und unterstützte Anforderungsparameter finden Sie unter Rendern einer Formularvorlage.

Wenn Benutzende eine Anfrage von einem Client-Gerät wie einem iOS- oder Android™-Browser starten, löst Sling zuerst den Profilknoten auf Basis der Anfrage-URL auf. Von diesem Profilknoten aus werden sling:resourceSuperType und sling:resourceType gelesen, um alle verfügbaren Skripte zu ermitteln, die diese Formular-Render-Anfrage verarbeiten können. Anschließend werden Sling-Anfrageselektoren zusammen mit der Anfragemethode verwendet, um das Skript zu identifizieren, das für die Verarbeitung dieser Anfrage am besten geeignet ist. Sobald die Anfrage ein Profil-Renderer-JSP erreicht, ruft das JSP den Forms OSGi-Dienst auf.

Weitere Informationen zur Sling-Skriptauflösung finden Sie unter AEM Sling-Spickzettel oder Apache Sling-URL-Zerlegung.

Typischer Formular-Verarbeitungsablauf typical-form-processing-call-flow

HTML5-Formulare speichert alle Zwischenobjekte zwischen, die für die Verarbeitung (Rendering oder Senden) eines Formulars bei der ersten Anforderung nötig sind. Die von den Daten abhängigen Objekte werden nicht zwischengespeichert, da sich diese wahrscheinlich ändern werden.

Formulare für Mobilgeräte verwalten zwei verschiedene Cache-Ebenen: PreRender-Cache und Render-Cache. Der PreRender-Cache enthält alle Fragmente und Bilder einer aufgelösten Vorlage und der Render-Cache enthält gerenderte Inhalte wie HTML.

Arbeitsablauf für HTML5-Formulare

Arbeitsablauf für HTML5-Formulare

HTML5-Formulare speichert Vorlagen nicht zwischen, die fehlende Verweise auf Fragmente und Bilder aufweisen. Wenn HTML5-Formulare länger als gewöhnlich lädt, prüfen Sie die Server-Protokolle auf fehlende Verweise und Warnungen. Stellen Sie auch sicher, dass die maximale Größe des Objekts nicht erreicht wurde.

Der Forms OSGi-Dienst verarbeitet eine Anfrage in zwei Schritten:

  • Erstellung des Layouts und des anfänglichen Formularstatus: Der Forms OSGi-Render-Dienst ruft die Forms-Cache-Komponente auf, um zu ermitteln, ob das Formular bereits zwischengespeichert und nicht invalidiert wurde. Wenn das Formular zwischengespeichert und validiert ist, wird das generierte HTML aus dem Cache bereitgestellt. Wenn das Formular ungültig ist, generiert der Forms OSGi-Render-Dienst das anfängliche Formularlayout und den Formularstatus im XML-Format. Diese XML-Datei wird vom Forms OSGi-Dienst in das HTML-Layout und den anfänglichen JSON-Formularstatus umgewandelt und dann für nachfolgende Anfragen zwischengespeichert.
  • Vorausgefüllte Formulare: Wenn ein Benutzer außerdem während des Renderings anfordert, dass Formulare vorab mit Daten ausgefüllt werden sollen, ruft der Forms OSGi-Renderdienst den Forms-Dienstcontainer auf und generiert einen neuen Formularstatus mit zusammengeführten Daten. Da das Layout jedoch bereits im obigen Schritt generiert wurde, ist dieser Aufruf schneller als der erste Aufruf. Dieser Aufruf führt nur die Datenzusammenführung durch und führt die Skripte für die Daten aus.

Wenn in einem Formular ein Update vorhanden ist oder Elemente verwendet werden, wird dies von der Formular-Cachekomponente erkannt, und der Cache für dieses bestimmte Formular ist ungültig. Sobald die Verarbeitung durch den Forms OSGi-Dienst abgeschlossen ist, fügt das Profil-Renderer-JSP JavaScript-Bibliotheksverweise und -stile zu diesem Formular hinzu und gibt die Antwort an den Client zurück. Hierfür kann ein typischer Webserver wie Apache mit aktivierter HTML-Komprimierung verwendet werden. Ein Webserver würde die Antwortgröße, den Netzwerkverkehr und die für das Streaming zwischen dem Server und dem Client-Rechner erforderliche Zeit erheblich verringern.

Wenn ein Benutzer das Formular ausfüllt, sendet der Browser den Formularstatus im JSON-Format an den Sendedienst-Proxy. Dann generiert der Sendedienst-Proxy eine Daten-XML mit JSON-Daten und sendet die Daten-XML an den Sende-Endpunkt.

Komponenten components

Sie benötigen das AEM Forms-Add-On-Paket, um HTML5-Formulare zu aktivieren. Informationen zum Installieren des AEM Forms-Add-on-Pakets finden Sie unter Installieren und Konfigurieren von AEM Forms.

OSGi-Komponenten (adobe-lc-forms-core.jar) osgi-components-adobe-lc-forms-core-jar

In der Bundle-Ansicht der Felix Admin-Konsole (https://[host]:[port]/system/console/bundles) wird als Name des OSGi-Bundles der HTML5-Formulare Adobe XFA Forms Renderer (com.adobe.livecycle.adobe-lc-forms-core) angezeigt.

Diese Komponente enthält OSGi-Komponenten für Rendering, Cache-Verwaltung und Konfigurationseinstellungen.

Forms OSGi-Dienst forms-osgi-service

Dieser OSGi-Dienst enthält die Logik zum Rendern einer XDP als HTML und verarbeitet die Übermittlung eines Formulars zum Generieren von Daten-XML. Dieser Dienst verwendet den Forms-Dienst-Container. Der Forms-Dienstcontainer ruft intern die native KomponenteXMLFormService.exe auf, die anschließend die Verarbeitung durchführt.

Wenn eine Render-Anforderung eingeht, ruft diese Komponente den Forms-Servicecontainer auf, um das Layout und die Statusinformationen zu generieren, die dann weiter verarbeitet werden, um den HTML- und JSON-DOM-Status eines Formulars zu generieren.

Diese Komponente ist auch für die Generierung von Daten-XML aus dem Status-JSON des gesendeten Formulars verantwortlich.

Cache-Komponente cache-component

HTML5-Formulare verwendet eine Zwischenspeicherung, um den Durchsatz zu maximieren und die Antwortzeit zu optimieren. Sie können die Ebene des Cache-Dienstes konfigurieren, um den Kompromiss zwischen Leistung und Platznutzung zu optimieren.

Cache-Strategie
Beschreibung
Ohne
Keine Artefakte zwischenspeichern
Konservativ
Nur Zwischenartefakte zwischenspeichern, die vor dem Rendering des Formulars generiert werden, z. B. Vorlagen mit Inline-Fragmenten und Bildern
Aggressiv
Den gerenderten HTML-Inhalt zwischenspeichern
Es werden alle Artefakte gespeichert, die in der Ebene „Konservativ“ zwischengespeichert wurden.
Hinweis: Diese Strategie führt zur besten Leistung, verbraucht jedoch mehr Speicher zum Speichern der zwischengespeicherten Artefakte.

HTML5-Formulare führt eine Zwischenspeicherung im Arbeitsspeicher durch und verwendet dafür die LRU-Strategie. Wenn die Cachestrategie auf „Keine“ gestellt ist, wird kein Cachespeicher erstellt, und alle Cachedaten (falls vorhanden) werden gelöscht. Neben der Cache-Strategie können Sie auch die Gesamtgröße des Arbeitsspeicher-Caches konfigurieren, um die maximale Cache-Größe zu begrenzen. Wenn sie überschritten wird, wird der LRU-Modus verwendet, um Cache-Ressourcen freizugeben.

NOTE
Der Arbeitsspeicher-Cache wird nicht zwischen Cluster-Knoten geteilt.

Konfigurationsdienst configuration-service

Der Konfigurationsdienst ermöglicht die Anpassung der Konfigurationsparameter und Cache-Einstellungen für HTML5-Formulare.

Wenn Sie diese Einstellungen aktualisieren möchten, wählen Sie in der CQ Felix Admin Console (verfügbar unter https://<'[server]:[port]'/system/console/configMgr) den Punkt Mobile Forms Configuration.

Sie können die Cache-Größe konfigurieren oder den Cache mithilfe des Konfigurationsdienstes deaktivieren. Sie können das Debugging auch mit dem Parameter „Debug Optionen“ aktivieren. Weitere Informationen über das Debugging von Formularen finden Sie unter Debugging von HTML5-Formularen.

Laufzeitkomponenten (adobe-lc-forms-runtime-pkg.zip) runtime-components-adobe-lc-forms-runtime-pkg-zip

Das Laufzeitpaket enthält die Client-seitigen Bibliotheken, die zum Rendern von HTML-Formularen verwendet werden.

Wichtige Komponenten, die als Teil des Laufzeitpakets verfügbar sind:

Scripting Engine scripting-engine

Die XFA-Implementierung von Adobe unterstützt zwei Arten von Skriptsprachen, um die Ausführung der benutzerdefinierten Logik in Formularen zu ermöglichen: JavaScript und FormCalc.

Die Scripting Engine von HTML Forms ist in JavaScript geschrieben, um die XFA-Skript-API in beiden Sprachen zu unterstützen.

Während des Renderns wird das FormCalc-Skript auf dem Server in JavaScript übersetzt (und zwischengespeichert), sodass es für die Person, die es verwendet oder gestaltet, transparent ist.

Diese Skripting-Engine verwendet einige Funktionen von ECMAScript5 wie „Object.defineProperty“. Die Engine/Bibliothek wird als CQ-Client-Bibliothek mit dem Kategorienamen xfaforms.profile bereitgestellt. Sie enthält auch die FormBridge API zur Interaktion externer Portale oder Apps mit dem Formular. Mit FormBridge kann eine externe App bestimmte Elemente programmgesteuert ausblenden, deren Werte abrufen oder festlegen oder deren Attribute ändern.

Weitere Informationen finden Sie im Artikel Form Bridge.

Layout-Engine layout-engine

Das Layout und das visuelle Erscheinungsbild von HTML5-Formulare basiert auf Funktionen von SVG 1.1, jQuery, BackBone und CSS3. Das anfängliche Erscheinungsbild eines Formulars wird generiert und auf dem Server zwischengespeichert. Das Ändern dieses anfänglichen Layouts und alle weiteren schrittweisen Änderungen am Formular-Layout werden auf dem Client verwaltet. Um dies zu erreichen, enthält das Laufzeitpaket eine Layout-Engine, die in JavaScript geschrieben ist und auf jQuery/Backbone basiert. Diese Engine verwaltet das gesamte dynamische Verhalten, wie das Hinzufügen/Entfernen wiederholbarer Instanzen und das Layout von Objekten, die vergrößert werden können. Diese Layout-Engine rendert nicht mehr als eine Formularseite gleichzeitig. Benutzende sehen zu Beginn nur eine Seite, und auch die horizontale Bildlaufleiste gilt nur für die erste Seite. Wenn allerdings abwärts gescrollt wird, beginnt das Rendern der nächsten Seite. Durch dieses Seite für Seite erfolgende Rendern wird weniger Zeit benötigt, um die erste Seite in einem Browser zu rendern, und die wahrgenommene Leistung des Formulars erhöht. Diese Engine/Bibliothek ist Teil der CQ-Client-Bibliothek mit dem Kategorienamen xfaforms.profile.

Die Layout-Engine enthält auch eine Reihe von Widgets, die verwendet werden, um den Wert von Formularfeldern einer Benutzerin bzw. eines Benutzers zu erfassen. Diese Widgets werden als jQuery UI-Widgets modelliert, die bestimmte zusätzliche Kontrakte für einen nahtlose Zusammenarbeit mit der Layout-Engine bereitstellen.

Weitere Informationen über Widgets und die entsprechenden Kontrakte finden Sie unter Benutzerdefinierte Widgets für HTML5-Formulare.

Stile styling

Die den HTML-Elementen zugeordneten Formatierungselemente werden entweder intern oder im eingebetteten CSS-Block hinzugefügt. Einige allgemeine Formatierungselemente, die nicht vom Formular abhängig sind, sind Teil der CQ-Client-Bibliothek mit dem Kategorienamen xfaforms.profile.

Zusätzlich zu den Standardformatierungseigenschaften enthält jedes Formularelement auch bestimmte CSS-Klassen, die auf dem Elementtyp, dem Namen und anderen Eigenschaften basieren. Mithilfe dieser Klassen können Sie Elemente durch Festlegen von deren eigener CSS umformatieren.

Weitere Informationen über Standardformatierung und Klassen finden Sie in der Einführung zu Stilen.

Server-seitiges Skript und Web-Dienste server-side-script-and-web-services

Skripte, die für eine Ausführung auf dem Server oder für den Aufruf eines Web-Dienstes markiert sind (unabhängig davon, wo dieser Web-Dienst ausgeführt werden soll), werden immer auf dem Server ausgeführt.

Die Client-Scripting Engine:

  1. Führt einen synchronen Aufruf an den Server durch und leitet den Status des aktuellen Formulars in Form von JSON an diesen weiter
  2. Führt das Skript oder den Web-Dienst auf dem Server aus
  3. Erstellt einen neuen JSON-Status
  4. Führt den neuen JSON-Status auf dem Client zusammen, wenn die Antwort zurückgegeben wird.

Lokalisierungsressourcen-Bundles localization-resource-bundles

HTML5-Formulare unterstützt die Sprachen Italienisch (it), Spanisch (es), Portugiesisch (Brasilien) (pt_BR), Chinesisch (vereinfacht) (zh_CN), Chinesisch (traditionell) (begrenzte Unterstützung) (zh_TW), Koreanisch (ko_KR), Englisch (en_US), Französisch (fr_FR), Deutsch (de_DE) und Japanisch (ja). Nach dem im Anforderungsheader empfangenen Gebietsschema richtet sich, welches Ressourcenbündel an den Client geleitet wird. Dieses Ressourcenbündel wird zur Profil-JSP als CQ-Client-Bibliothek mit dem Kategorienamen xfaforms.I18N hinzugefügt. Sie können die Logik überschreiben, dass das Gebietsschema-Paket im Profil aufgenommen wird.

Sling-Komponenten (adobe-lc-forms-content-pkg.zip) sling-components-adobe-lc-forms-content-pkg-zip

Das Sling-Paket enthält Inhalte zu den Profilen und zum Profil-Renderer.

Profile profiles

Profile sind die Ressourcenknoten in Sling, die ein Formular oder eine Familie von Formularen repräsentieren. Auf CQ-Ebene sind diese Profile JCR-Knoten. Die Knoten befinden sich im Ordner /content im JCR-Repository und können sich auch in allen Unterordnern des Ordners /content befinden.

Profil-Renderer profile-renderers

Der Profilknoten hat eine Eigenschaft Sling: resourceSuperType mit dem Wert xfaforms/profile. Diese Eigenschaft sendet intern Anforderungen an das Sling-Skript für Profilknoten im /libs/xfaforms/profile Ordner. Diese Skripte sind JSP-Seiten, die als Container für die Zusammenfügung der HTML-Formulare und der erforderlichen JS/CSS-Artefakte dienen. Die Seiten enthalten Verweise auf:

  • xfaforms.I18N.<locale>: Diese Bibliothek enthält lokalisierte Daten.
  • xfaforms.profile: Diese Bibliothek enthält die Implementierung für XFA Scripting und für die Layout-Engine.

Diese Bibliotheken sind als CQ-Client-Bibliotheken modelliert, um Nutzen aus den automatischen Verkettungs-, Minimierungs- und Komprimierungsfunktionen der CQ Framework JavaScript-Bibliotheken zu ziehen.
Weitere Informationen zu CQ-Client-Bibliotheken finden Sie unter Dokumentation zu CQ Client-Bibliotheken.

Wie oben beschrieben ruft der Profil-Renderer-JSP den Forms-Service über ein Sling-Include auf. Dieses JSP legt auch verschiedene Debugging-Optionen auf Basis der Admin-Konfiguration oder von Anfrageparametern ein.

HTML5-Formulare ermöglicht Entwicklern, Profile und Profil-Renderer zu erstellen, um das Erscheinungsbild der Formulare anzupassen. Beispielsweise können Entwickler HTML-Formulare in ein Bedienfeld oder einen <div>-Abschnitt eines vorhandenen HTML-Portals integrieren.
Weitere Informationen über das Erstellen benutzerdefinierter Profile finden Sie unter Erstellen eines benutzerfreundlichen Profils.

recommendation-more-help
19ffd973-7af2-44d0-84b5-d547b0dffee2