Show Menu
THEMEN×

Architektur of HTML5 forms

Architektur

HTML5 forms functionality is deployed as a package within the embedded AEM instance and is exposesd as a REST end point over HTTP/S using RESTful Apache Sling Architecture .
[ ![01-aem-forms-architecture](assets/01-aem-forms-architecture.jpg)

Ansicht in voller Größe ](javascript:void(0).md)
[ ![02-aem-forms-architecture_large](assets/02-aem-forms-architecture_large.jpg)](javascript:void(0).md)

Über das Sling Framework

Apache Sling ist ressourcenzentriert. Es verwendet zunächst eine Anforderungs-URL, um die Ressource aufzulösen. Jede Ressource hat eine sling:resourceType (oder sling:resourceSuperType )-Eigenschaft. Anhand dieser Eigenschaft, der Anforderungsmethode und der Eigenschaften der Anforderungs-URL wird ein Sling-Skript ausgewählt, um die Anforderung zu bearbeiten. 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.
For details on REST endpoint and supported request parameters, see Rendering Form Template .
Wenn ein Benutzer eine Anforderung von einem Client-Gerät wie einem iOS- oder Android-Browser abgibt, löst Sling zuerst den Profil-Knoten basierend auf der Anforderungs-URL auf. Aus diesem Profilknoten liest es sling:resourceSuperType und sling:resourceType aus, um alle verfügbaren Skripten zu ermitteln, die diese Anforderung, ein Formular zu rendern, bearbeiten können. Abschließend verwendet es Sling-Anforderungsselektoren zusammen mit der Anforderungsmethode, um das Skript zu identifizieren, das am besten für die Bearbeitung dieser Anforderung geeignet ist. Wenn die Anforderung ein Profil-Renderer-JSP erreicht, ruft das JSP den Forms OSGi-Dienst auf.
Weitere Informationen zur Auflösung von Sling-Skripten finden Sie unter AEM Sling-Spickzettel oder Apache Sling-URL-Auflösung .

Typisches Formular zur Verarbeitung von Call-Flows

HTML5-Formulare speichert alle Zwischenobjekte zwischen, die für die Verarbeitung (Rendering oder Senden) eines Formulars bei der ersten Anforderung nötig sind. Objekte, die von Daten abhängig sind, werden nicht zwischengespeichert, da diese wahrscheinlich geändert werden.
Mobile Forms bietet zwei unterschiedliche Zwischenspeicher-Ebenen: den PreRender-Cache und den Render-Cache. Der PreRender-Cache enthält alle Fragmente und Bilder einer gelösten Vorlage und Render-Cache enthält gerenderten Inhalt wie HTML.
für HTML5-Formulare Abbildung: 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 Anforderung in zwei Schritten:
  • Generierung eines Layouts und des anfänglichen Formularstatus : Der Forms OSGi-Renderdienst ruft die Formular-Cachekomponente auf, um zu bestimmen, ob das Formular bereits zwischengespeichert wurde und ob es noch gültig ist. Wenn das Formular zwischengespeichert und gültig ist, liefert es das generierte HTML aus dem Cache. 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 HTML-Layout und in den anfänglichen JSON-Formularstatus umgewandelt sowie für folgende Anforderungen zwischengespeichert.
  • Vorausgefüllte Formulare : Beim Rendern ruft der Forms OSGi-Renderdienst den Forms-Dienst Container auf und generiert einen neuen Formularstatus mit zusammengeführten Daten. Da das Layout jedoch schon im ersten Schritt generiert wird, ist dieser Aufruf schneller als der erste. Dieser Aufruf führt nur die Zusammenführung von Daten durch und führt die Skripten auf den Daten aus.
Wenn ein Formular aktualisiert wurde oder Elemente in einem Formular verwendet wurden, erkennt die Formular-Cache-Komponente es und der Cache für dieses bestimmte Formular wird ungültig. Wenn die Verarbeitung durch den Forms OSGi-Dienst abgeschlossen ist, fügt das Profil-Renderer-JSP JavaScript-Bibliotheksverweise in das Formular ein 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 der Daten zwischen Server und Clientcomputer erforderliche Zeit erheblich verringern.
When a user submits the form, the browser sends state of form in JSON format to the submit service proxy ; then the submit service proxy generates a data XML using JSON data and submits that data XML to submit endpoint.

Komponenten

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

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

Adobe XFA Forms Renderer (com.adobe.livecycle.adobe-lc-forms-core) ist der Anzeigename des HTML5 Forms OSGi-Bundles, wenn er von der Bundle-Ansicht der Felix Admin Console angezeigt wird (https:// #: #/system/console/bundles).
Diese Komponente enthält OSGi-Komponenten für Rendering, Cachemanagement und Konfigurationseinstellungen.

Forms OSGi-Dienst

Dieser OSGi-Dienst enthält die Logik zum Rendern einer XDP als HTML und verarbeitet Sendungen von Formularen zur Generierung einer Daten-XML. Dieser Dienst verwendet Forms-Dienstcontainer. Der Forms-Dienstcontainer ruft intern die native Komponente XMLFormService.exe auf, die anschließend die Verarbeitung durchführt.
Wenn eine Renderanforderung empfangen wird, ruft diese Komponente den Forms-Dienst-Container auf, um Layout- und Statusinformationen zu generieren, die weiter verarbeitet werden, um HTML- und JSON-Formular-DOM-Status zu generieren.
Diese Komponente ist auch für die Generierung der Daten-XML aus dem Status-JSON des gesendeten Formulars zuständig.

Cachekomponente

HTML5-Formulare verwendet eine Zwischenspeicherung, um den Durchsatz zu maximieren und die Antwortzeit zu optimieren. Sie können die Ebene des Cachedienstes konfigurieren, um einen Kompromiss zwischen Leistung und Platznutzung festzulegen.
Cachestrategie Beschreibung
Keine Keine Artefakte zwischenspeichern
Konservativ Es werden nur Zwischenartefakte zwischengespeichert, die vor dem Rendering des Formulars generiert werden, z. B. die Vorlage, die die Inline-Fragmente und Bilder enthält.
Stark Den gerenderten HTML-Inhalt zwischenspeichern Es werden alle Artefakte gespeichert, die in der Ebene "Konservativ" zwischengespeichert wurden. Hinweis : Diese Strategie ergibt die beste Leistung, verbraucht jedoch mehr Platz für die Speicherung 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. Außer der Cachestrategie können Sie auch die Größe des gesamten Arbeitsspeichercaches konfigurieren. Dies kann hilfreich sein, um die maximale Cachegröße festzulegen und, falls diese überschritten wird, mithilfe des LRU-Modus Cacheressourcen freizugeben.
Der Arbeitsspeichercache wird nicht zwischen Clusterknoten freigegeben.

Konfigurationsdienst

Der Konfigurationsdienst ermöglicht die Einstellung der Konfigurationsparameter und der Cacheeinstellungen für HTML5-Formulare.
To update these settings, go to the CQ Felix Admin Console (available at https://[server]:[port]/system/console/configMgr ), search for and select Mobile Forms Configuration.
Mit dem Konfigurationsdienst können Sie die Cachegröße konfigurieren oder den Cache deaktivieren. Sie können auch mithilfe des Parameters „Debug Options“ das Debugging aktivieren. More information about debugging forms can be found at Debugging HTML5 forms .

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

Das Laufzeitpaket enthält die clientseitigen Bibliotheken, die verwendet werden, um HTML-Formulare zu rendern.
Im Laufzeitpaket verfügbare wichtige Komponenten:

Scripting Engine

Die Implementierung von Adobe XFA unterstützt zwei Arten von Skriptsprachen, um die Ausführung einer benutzerdefinierten Logik in Formularen zu aktivieren: JavaScript und FormCalc.
Die Scripting Engine für HTML-Formulare ist in JavaScript geschrieben, um die XFA-Skript-API in diesen beiden Sprachen zu unterstützen.
Während des Renderns wird das FormCalc-Skript für den Benutzer oder Designer sichtbar in JavaScript übersetzt (und zwischengespeichert).
Die Scripting Engine verwendet einige der Funktionen von ECMAScript5, z. B. 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, ihre Werte abrufen oder einstellen oder ihre Attribute ändern.
Weitere Informationen finden Sie im Artikel Form Bridge .

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 auf dem Server erstellt und zwischengespeichert. Die Optimierung dieses ersten Layouts und alle anderen schrittweisen Änderungen am Formularlayout 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 dynamisches 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. Der Benutzer sieht zu Anfang nur eine Seite, und auch die horizontale Bildlaufleiste gilt nur für die erste Seite. Wenn der Benutzer allerdings abwärts scrollt, beginnt das Rendering der nächsten Seite. Dieses Seite für Seite erfolgende Rendering verringert den Zeitraum, der benötigt wird, um die erste Seite in einem Browser zu rendern, und erhöht die wahrgenommene Leistung des Formulars. 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 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

Der Stil, der den HTML-Elementen zugeordnet ist, wird entweder inline oder basierend auf dem 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 unter Einführung zu Stilen .

Serverseitiges Skript und Webdienste

Skripten, die für eine Ausführung auf dem Server oder für den Aufruf eines Webdienstes markiert sind (unabhängig davon, wo dieser Webdienst 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 Webdienst 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

HTML5-Formulare unterstützen die Sprachen Italienisch (it), Spanisch (es), Brasilianisches Portugiesisch (pt_BR), Vereinfachtes Chinesisch (zh_CN), Traditionelles Chinesisch (nur 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)

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

Profile

Profile sind die Ressourcenknoten im Sling, die ein Formular oder eine Familie von Formularen repräsentieren. Auf der 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

Der Profilknoten hat ein Eigenschafts- Sling: resourceSuperType mit dem Wert xfaforms/profile . This property internally sends forward requests to the sling script for Profile nodes located in the /libs/xfaforms/profile folder. Diese Skripten 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 Formulardienst über einen Sling auf. Dieses JSP legt auch verschiedene Debugging-Optionen auf Basis der Admin-Konfiguration oder von Anforderungsparametern 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 .