Sie sehen sich Hilfeinhalte der folgenden Version an:

Einführung

In AEM Forms Workspace werden mehrere Formulartypen nahtlos unterstützt. Hierzu gehören:

  • PDF-Formulare (XDP/Acroform/Flache PDF-Dateien)
  • Neue HTML-Formulare
  • Bilder
  • Drittanbieteranwendungen (zum Beispiel Correspondence Management)
In diesem Dokument wird die Verwendung dieser Renderer aus der Perspektive der semantischen Anpassung bzw. der Komponentenwiederverwendung erläutert, sodass Kundenanforderungen erfüllt werden, ohne eine Darstellung zu beeinträchtigen. Obwohl AEM Forms Workspace beliebige Änderungen der Benutzeroberfläche oder der Bedeutung zulässt, wird empfohlen, die Renderlogik von verschiedenen Formulartypen nicht zu ändern. Andernfalls können die Ergebnisse unvorhersehbar sein. Dieses Dokument dient zur Anleitung und zum Verständnis für das Rendering desselben Formulars mit den gleichen Workspace-Komponenten auf verschiedenen Portalen, nicht zum Ändern der Renderlogik selbst.

PDF-Formulare

PDF-Formulare werden durch die PdfTaskForm-Ansicht gerendert.

Wenn ein XDP-Formular als PDF-Datei gerendert wird, wird ein FormBridge JavaScript™ vom FormsAugmenter-Dienst hinzugefügt. Dieses JavaScript™ (innerhalb des PDF-Formulars) hilft bei Aktionen wie dem Senden und Speichern von Formularen oder dem Offlineschalten des Formulars.

In AEM Forms Workspace kommuniziert die Ansicht PDFTaskForm mit dem FormBridge-Javascript über einen HTML-Zwischencode, der unter /lc/libs/ws/libs/ws/pdf.html gespeichert ist. Der Fluss verläuft wie folgt:

PDFTaskForm-Ansicht – pdf.html

Kommuniziert mithilfe von window.postMessage / window.attachEvent ('Meldung')

Diese Methode ist das Standardverfahren zur Kommunikation zwischen einem übergeordneten Frame und einem iframe. Die vorhandenen Ereignis-Listener von zuvor geöffneten PDF-Formularen werden entfernt, bevor ein neuer hinzugefügt wird. Bei dieser Löschung wird auch der Wechsel zwischen Formular-Registerkarte und Verlaufs-Registerkarte in der Aufgabendetailansicht berücksichtigt.

pdf.html – FormBridge-Javascript innerhalb der gerenderten PDF-Datei

Kommuniziert mithilfe von pdfObject.postMessage / pdfObject.messageHandler

Diese Methode ist das Standardverfahren zur Kommunikation aus HTML mit einem PDF-Javascript. Die PdfTaskForm-Ansicht behandelt auch flaches PDF und rendert es einfach.

Hinweis:

Es wird nicht empfohlen, die Datei pdf.html oder den Inhalt der PdfTaskForm-Ansicht zu ändern.

Neue HTML-Formulare

Neue HTML-Formulare werden durch die NewHTMLTaskForm-Ansicht gerendert.

Wenn ein XDP-Formular mit dem in CRX bereitgestellten Mobile Forms-Paket als HTML gerendert wird, wird dem Formular auch zusätzliches FormBridge-Javascript hinzugefügt, das verschiedene Methoden für das Speichern und Senden von Formulardaten verfügbar macht.

Dieses Javascript unterscheidet sich von dem, auf das oben unter „PDF-Formulare“ verwiesen wird, erfüllt jedoch einen ähnlichen Zweck.

Hinweis:

Es wird nicht empfohlen, den Inhalt der NewHTMLTaskForm-Ansicht zu ändern.

Flex-Formulare und Guides

Flex-Formulare werden durch die Ansicht SwfTaskForm gerendert, Guides durch die Ansicht HtmlTaskForm.

In AEM Forms Workspace kommunizieren diese Ansichten mit dem tatsächlichen SWF, aus dem das Flex-Formular bzw. der Guide besteht, über einen Zwischen-SWF-Code, der in /lc/libs/ws/libs/ws/WSNextAdapter.swf gespeichert ist.

Die Kommunikation erfolgt mithilfe von swfObject.postMessage oder window.flexMessageHandler.

Dieses Protokoll wird durch WsNextAdapter.swf definiert. Die vorhandenen flexMessageHandlers im window-Objekt von zuvor geöffneten SWF-Formularen werden entfernt, bevor ein neuer hinzugefügt wird. Bei dieser Logik wird auch der Wechsel zwischen Formular-Registerkarte und Verlaufs-Registerkarte in der Aufgabendetailansicht berücksichtigt. WsNextAdapter.swf wird zum Ausführen verschiedener Formularaktionen wie Speichern oder Senden verwendet.

Hinweis:

Es wird nicht empfohlen, WSNextAdapter.swf oder den Inhalt der Ansichten SwfTaskForm bzw. HtmlTaskForm zu ändern.

Drittanbieteranwendungen (zum Beispiel Correspondence Management)

Drittanbieteranwendungen werden mithilfe der ExtAppTaskForm-Ansicht gerendert.

Kommunikation zwischen Drittanbieteranwendungen und AEM Forms Workspace

AEM Forms Workspace hört window.global.postMessage([Message], [Payload]) ab.

[Message] kann eine in der runtimeMap als SubmitMessage | CancelMessage | ErrorMessage | actionEnabledMessage angegebene Zeichenfolge sein. Drittanbieteranwendungen müssen diese Schnittstelle verwenden, um AEM Forms Workspace nach Bedarf zu benachrichtigen. Die Verwendung dieser Schnittstelle ist obligatorisch, da AEM Forms Workspace wissen muss, wann die Aufgabe gesendet wird, damit das Aufgabenfenster bereinigt werden kann.

Kommunikation zwischen AEM Forms Workspace und Drittanbieteranwendungen

Wenn die Schaltflächen zur direkten Aktion von AEM Forms Workspace sichtbar sind, erfolgt ein Aufruf von window.[External-App-Name].getMessage([Action]), wobei [Action] aus der routeActionMap gelesen wird. Die Drittanbieteranwendung muss diese Schnittstelle abhören und benachrichtigt dann AEM Forms Workspace über die postMessage()-API.

Beispielsweise kann eine Flex-Anwendung ExternalInterface.addCallback('getMessage', listener) definieren, um diese Kommunikation zu unterstützen. Wenn in der Drittanbieteranwendung das Senden von Formularen über eigene Schaltflächen behandelt wird, sollten Sie hideDirectActions  = true() in der runtimemap angeben, und Sie können diesen Listener überspringen. Daher ist dieses Konstrukt optional.

Weitere Informationen zur Integration von Drittanbieteranwendungen in Bezug auf Correspondence Management finden Sie unter Integrieren von Correspondence Management in AEM Forms Workspace.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie