In AEM Forms workspace, multiple form types are supported seamlessly. These include:
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 same workspace components in different portals, and not for modifying the rendering logic itself.
PDF forms are rendered by
When an XDP form is rendered as PDF, a
In AEM Forms workspace, PDFTaskForm view communicates with the
/lc/libs/ws/libs/ws/pdf.html. The flow is:
PDFTaskForm view - pdf.html
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 task details view.
It is not recommended to modify the pdf.html / contents of PdfTaskForm view.
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
It is not recommended to modify the contents of NewHTMLTaskForm view.
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
The communication happens using
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 task details view.
WsNextAdapter.swf is used for performing various form actions like save or submit.
It is not recommended to modify
WSNextAdapter.swf or the contents of SwfTaskForm / HtmlTaskForm view.
Third-party applications are rendered using ExtAppTaskForm view.
Third-party application to AEM Forms workspace communication
AEM Forms workspace listens on
[Message] can be a string specified as
runtimeMap. Third-party applications must use this interface to notify 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
[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 on third-party application integration with respect to Correspondence Management at Integrating Correspondence Management in AEM Forms workspace.