Document details for renderer

Last update: June 24, 2024

CREATED FOR:

  • Admin
  • User
  • Developer

Introduction

In the AEM Forms workspace, multiple form types are supported seamlessly. These include:

  • PDF forms (XDP / Acroform / Flat PDFs)
  • New HTML forms
  • Images
  • Third-party applications (for example, Correspondence Management)

This document explains the working of these renderers from the perspective of semantic customization / component reuse, so that customer requirements are met without breaking any rendition. While AEM Forms workspace allows for any user interface / semantic changes, it is recommended that the rendering logic of different form types not be changed, otherwise the results can be unpredictable. This document is for guidance / knowledge to support rendering the same form, using the same workspace components in different portals, and not for modifying the rendering logic itself.

PDF Forms

PDF forms are rendered by PdfTaskForm View.

When an XDP form is rendered as PDF, a FormBridge JavaScript™ is added by FormsAugmenter service. This JavaScript™ (inside the PDF form) helps in performing actions like form submit, form save, or taking form offline.

In AEM Forms workspace, PDFTaskForm view communicates with the FormBridgeJavaScript, by way of an intermediary HTML present at /lc/libs/ws/libs/ws/pdf.html. The flow is:

PDFTaskForm view - pdf.html

Communicates using window.postMessage / window.attachEvent('message')

This method is the standard way of communication between a parent frame and an iframe. The existing event listeners from previously opened PDF forms are removed before adding a new one. This purging also considers the switching between form tab and history tab in the task details view.

pdf.html - FormBridgeJavaScript inside the rendered PDF

Communicates using pdfObject.postMessage / pdfObject.messageHandler

This method is the standard way of communication with a PDFJavaScript from an HTML. PdfTaskForm view also takes care of a flat PDF and renders it plain.

NOTE
It is not recommended to edit the pdf.html / contents of the PdfTaskForm view.

New HTML Forms

New HTML forms are rendered by NewHTMLTaskForm View.

When an XDP Form is rendered as HTML using the mobile forms package deployed on CRX, it also adds additional FormBridgeJavaScript to the form, which exposes different methods for saving and submitting form data.

This JavaScript is different from the one referred to in PDF Forms above, but serves a similar purpose.

NOTE
Adobe does not recommend editing the contents of the NewHTMLTaskForm view.

Flex Forms and Guides

Flex Forms are rendered by SwfTaskForm and guides are rendered by HtmlTaskForm Views respectively.

In AEM Forms workspace, these views communicate with the actual SWF which makes up the Flex® form/guide using an intermediary SWF present at /lc/libs/ws/libs/ws/WSNextAdapter.swf

The communication happens using swfObject.postMessage / window.flexMessageHandler.

This protocol is defined by the WsNextAdapter.swf. The existing flexMessageHandlerson window object, from previously opened SWF forms are removed before adding a new one. The logic also considers the switching between form tab and history tab in the task details view. The WsNextAdapter.swf is used to perform various form actions like save or submit.

NOTE
It is not recommended to modify WSNextAdapter.swf or the contents of SwfTaskForm / HtmlTaskForm view.

Third-party applications (for example, Correspondence Management)

Third-party applications are rendered using the ExtAppTaskForm view.

Third-party application to AEM Forms workspace communication

AEM Forms workspace listens on window.global.postMessage([Message],[Payload])

[Message] can be a string specified as SubmitMessage| CancelMessage| ErrorMessage| actionEnabledMessagein the runtimeMap. Third-party applications must use this interface to notify the AEM Forms workspace as needed. Using this interface is mandatory, because the AEM Forms workspace must know that when the task is submitted so that it can clean up the task window.

AEM Forms workspace to third-party application communication

If AEM Forms workspace’s direct action buttons are visible, it calls window.[External-App-Name].getMessage([Action]), where [Action] is read from the routeActionMap. The third-party application must listen on this interface, and then notify AEM Forms workspace via the postMessage () API.

For example, a Flex application can define ExternalInterface.addCallback('getMessage', listener) to support this communication. If the third-party application wants to handle form submission via its own buttons, then you should specify hideDirectActions = true() in the runtimeMap and you may skip this listener. Hence, this construct is optional.

You can read more about third-party application integration regarding Correspondence Management at Integrating Correspondence Management in the AEM Forms workspace.

Experience Manager


Espressos & Experience Manager: AEM Forms

Espressos & Experience Manager

Thursday, Mar 6, 7:00 PM UTC

Join Adobe's AEM product team as they highlight AEM Forms' latest innovations, including: the new Gen AI Assistant, Unified Composition with AEM Sites, and new ways to deploy forms through conversations.

Register

Connect with Experience League at Summit!

Get front-row access to top sessions, hands-on activities, and networking—wherever you are!

Learn more

Register now