Nell’area di lavoro di AEM Forms, sono supportati senza problemi più tipi di modulo. Comprendono:
Questo documento spiega il funzionamento di questi renderer dal punto di vista della personalizzazione semantica e del riutilizzo dei componenti, in modo da soddisfare i requisiti dei clienti senza interrompere alcuna rappresentazione. Sebbene l’area di lavoro di AEM Forms consenta qualsiasi modifica semantica o all’interfaccia utente, si consiglia di non modificare la logica di rendering dei diversi tipi di modulo, altrimenti i risultati potrebbero essere imprevedibili. Questo documento offre indicazioni e supporto per il rendering dello stesso modulo, l’utilizzo degli stessi componenti dell’area di lavoro in portali diversi e non per la modifica della logica di rendering.
Il rendering dei PDF forms viene eseguito da PdfTaskForm View
.
Quando si esegue il rendering di un modulo XDP come PDF, viene FormBridge
JavaScript™ viene aggiunto dal servizio FormsAugmenter. Questo JavaScript™ (all’interno del modulo PDF) consente di eseguire azioni quali l’invio di un modulo, il salvataggio di un modulo o la disconnessione del modulo.
Nell’area di lavoro di AEM Forms, la vista PDFTaskForm comunica con FormBridge
JavaScript, tramite un HTML intermediario presente all’indirizzo /lc/libs/ws/libs/ws/pdf.html
. Il flusso è:
Vista PDFTaskForm - pdf.html
Comunica tramite window.postMessage
/ window.attachEvent('message')
Questo metodo è il metodo standard di comunicazione tra un frame principale e un iframe. I listener di eventi esistenti dai PDF forms aperti in precedenza vengono rimossi prima di aggiungerne uno nuovo. Questa rimozione considera anche il passaggio tra la scheda del modulo e la scheda della cronologia nella visualizzazione dei dettagli dell’attività.
pdf.html - FormBridge
JavaScript all’interno del PDF di cui è stato eseguito il rendering
Comunica tramite pdfObject.postMessage
/ pdfObject.messageHandler
Questo metodo è il metodo standard di comunicazione con un PDFJavaScript di un HTML. La visualizzazione PdfTaskForm si occupa anche di un PDF piatto e lo rende semplice.
Si sconsiglia di modificare il contenuto pdf.html/della visualizzazione PdfTaskForm.
Il rendering dei nuovi moduli HTML viene eseguito dalla vista NewHTMLTaskForm.
Quando viene eseguito il rendering di un modulo XDP come HTML utilizzando il pacchetto di moduli mobili distribuito su CRX, vengono aggiunti anche altri FormBridge
JavaScript per il modulo, che espone diversi metodi per salvare e inviare i dati del modulo.
Questo JavaScript è diverso da quello a cui si fa riferimento nei PDF forms precedenti, ma ha uno scopo simile.
L'Adobe non consiglia di modificare il contenuto della visualizzazione NewHTMLTaskForm.
Il rendering dei Forms di Flex viene eseguito da SwfTaskForm e il rendering delle guide viene eseguito rispettivamente da HtmlTaskForm Views.
Nell’area di lavoro di AEM Forms, queste visualizzazioni comunicano con il SWF effettivo che costituisce il modulo o la guida del Flex® utilizzando un SWF intermedio presente in /lc/libs/ws/libs/ws/WSNextAdapter.swf
La comunicazione avviene utilizzando swfObject.postMessage
/ window.flexMessageHandler
.
Questo protocollo è definito dal WsNextAdapter.swf
. L'esistente flexMessageHandlers
in un oggetto finestra, i form SWF aperti in precedenza vengono rimossi prima di aggiungerne uno nuovo. La logica considera anche il passaggio tra la scheda del modulo e la scheda della cronologia nella visualizzazione dei dettagli dell’attività. Il WsNextAdapter.swf
viene utilizzato per eseguire varie azioni del modulo, ad esempio salva o invia.
Non è consigliabile modificare WSNextAdapter.swf
o il contenuto della visualizzazione SwfTaskForm/HtmlTaskForm.
Il rendering delle applicazioni di terze parti viene eseguito utilizzando la vista ExtAppTaskForm.
Applicazione di terze parti per la comunicazione nell’area di lavoro di AEM Forms
L’area di lavoro AEM Forms è in ascolto window.global.postMessage([Message],[Payload])
[Messaggio] può essere una stringa specificata come SubmitMessage
| CancelMessage
| ErrorMessage
| actionEnabledMessage
nel runtimeMap
. Le applicazioni di terze parti devono utilizzare questa interfaccia per inviare le notifiche necessarie all’area di lavoro di AEM Forms. L’utilizzo di questa interfaccia è obbligatorio perché l’area di lavoro di AEM Forms deve sapere quando l’attività viene inviata in modo da poter pulire la finestra dell’attività.
Comunicazione tra AEM Forms Workspace e applicazioni di terze parti
Se i pulsanti di azione diretta dell’area di lavoro AEM Forms sono visibili, effettua una chiamata window.[External-App-Name].getMessage([Action])
, dove [Action]
viene letto da routeActionMap
. L’applicazione di terze parti deve rimanere in ascolto su questa interfaccia, quindi inviare una notifica all’area di lavoro di AEM Forms tramite postMessage ()
API.
Ad esempio, un’applicazione Flex può definire ExternalInterface.addCallback('getMessage', listener)
a sostegno di questa comunicazione. Se l’applicazione di terze parti desidera gestire l’invio del modulo tramite i propri pulsanti, è necessario specificare hideDirectActions = true() in the runtimeMap
e questo listener può essere ignorato. Pertanto, questo costrutto è facoltativo.
Per ulteriori informazioni sull’integrazione di applicazioni di terze parti relative alla gestione della corrispondenza, consulta Integrazione della gestione della corrispondenza nell’area di lavoro di AEM Forms.