Mobile Forms-Architektur

Mobile Forms wird als Paket innerhalb der eingebetteten CQ-Instanz bereitgestellt und stellt mithilfe einer REST-konformen Apache Sling Architecture Funktionen wie REST-Endpunkte über HTTP/S bereit.

 

Ü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 Mobile Forms 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 ein Benutzer eine Anforderung von einer Clientanwendung wie einem iOS- oder Android-Browser startet, löst Sling zuerst den Profilknoten auf Basis 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

Mobile Forms 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. 

Mobile Forms speichert Vorlagen nicht zwischen, die fehlende Verweise auf Fragmente und Bilder aufweisen. Wenn Mobile Forms 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, ruft der Forms OSGi-Renderdienst den LiveCycle Forms-Dienstcontainer auf, der das anfängliche Formularlayout und den Formularstatus im XML-Format generiert. 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: 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 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.
  

Ein zu renderndes Formular kann sich im LiveCycle Repository befinden. 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. 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 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

Bereitstellbare Einheiten

Mobile Forms wird als CQ-Paket bereitgestellt, das vom CQ-Paket-Manager verwaltet werden kann, der unter http://:/lc/crx/packmgr/index.jsp verfügbar ist.

adobe-lc-forms-pkg.zip: Dieses Paket ist das Haupt-Einzelinstallationspaket. Dieses Paket enthält folgende untergeordnete Pakete und Bundles:

• adobe-lc-forms-core-<version>.jar: Ein OSGi-Bundle, das die OSGi-Komponenten und -Dienste enthält, die von Mobile Forms verwendet werden.
  
• scala-lang-2.9.1.jar: Das Bundle adobe-lc-forms-core enthält eine Reihe von Scala-Bibliotheken, die von scala-lang-2.9.1.jar verwendet werden.
  
• adobe-lc-forms-runtime-pkg-<version>.zip Dieses Paket enthält JavaScript-Laufzeitbibliotheken, wie die Scripting Engine, die Layout-Engine und CSS.
  
• adobe-lc-forms-content-pkg-<version>.zip: In diesem Paket sind Profil- und Profil-Renderer-Skripten und einige andere Ressourcen enthalten.
• adobe-lc-forms-lcconnector-<Version>.jar: Dieses OSGi-Bundle enthält alle Dienstimplementierungen für LiveCycle.
  
  

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

In der Bundle-Ansicht der Felix Admin-Konsole (http://<host>: <Port>/lc/system/console/bundles) wird als Name des Mobile Forms OSGi-Bundles Adobe XFA Forms Renderer (com.adobe.livecycle.adobe-lc-forms-core) angezeigt.

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 LiveCycle Forms-Dienstcontainer. 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-Dienstcontainer 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 der Daten-XML aus dem Status-JSON des gesendeten Formulars zuständig.

Cachekomponente

Mobile Forms 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.

Mobile Forms 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. Die LRU-Verdrängungsstrategie basiert auf der Formularanzahl. Sie können auch den Schwellenwert festlegen, ab dem Objekte nicht mehr zwischengespeichert werden sollen.

Konfigurationsdienst

Der Konfigurationsdienst ermöglicht die Einstellung der Konfigurationsparameter und der Cacheeinstellungen für Mobile Forms.

Wenn Sie diese Einstellungen aktualisieren möchten, wählen Sie in der CQ Felix Admin-Konsole (verfügbar unter http://<Server>:<Port>/lc/system/console/configMgr) den Punkt LC Forms Configuration.

Mit dem Konfigurationsdienst können Sie die Cachegröße konfigurieren oder den Cache deaktivieren. Detaillierte Informationen finden Sie unter Cache-Komponente. Sie können auch mithilfe des Parameters „Debug Options“ das Debugging aktivieren. Weitere Informationen über das Debugging von Formularen finden Sie unter Debugging von Mobile 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 Mobile Forms 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 Kategorienamenxfaforms.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 Mobile Forms.

Formatierung

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 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

Standardmäßig wird Mobile Forms in englischer, französischer, deutscher und japanischer Sprache unterstützt. 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. Diese Eigenschaft sendet intern Anforderungen an das Sling-Skript für Profilknoten im Ordner /libs/xfaforms/profile. 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.   Mobile Forms ermöglicht Entwicklern, Profile und Profil-Renderer zu erstellen, um das Erscheinungsbild der Formulare anzupassen. Beispielsweise kann ein Entwickler in Mobile Forms ein Formular 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.