Rendering di Forms come HTML rendering-forms-as-html

Gli esempi e gli esempi contenuti in questo documento sono solo per AEM Forms in ambiente JEE.

Il servizio Forms esegue il rendering dei moduli come HTML in risposta a una richiesta HTTP da un browser web. Un vantaggio del rendering di un modulo come HTML è che il computer in cui si trova il browser web client non richiede Adobe Reader, Acrobat o Flash Player (per le guide dei moduli, è obsoleto).

Per eseguire il rendering di un modulo come HTML, è necessario salvare la struttura del modulo come file XDP. Non è possibile eseguire il rendering come HTML di una struttura di modulo salvata come file PDF. Quando si sviluppa in Designer una progettazione di modulo che verrà sottoposta a rendering come HTML, considera i seguenti criteri:

Pagine HTML html-pages

Quando si esegue il rendering di una struttura di modulo come modulo HTML, ogni sottomaschera di secondo livello viene riprodotto come pagina HTML (pannello). È possibile visualizzare la gerarchia di una sottomaschera in Designer. Le sottomaschere secondarie che appartengono alla sottomaschera principale (il nome predefinito di una sottomaschera principale è form1) sono le sottomaschere del pannello. Nell'esempio seguente vengono illustrate le sottomaschere di una struttura di maschera.

     form1
         Master Pages
         PanelSubform1
             NestedDynamicSubform
                 TextEdit1
         PanelSubform2
             TextEdit1
         PanelSubform3
             TextEdit1
         PanelSubform4
             TextEdit1

Quando le progettazioni dei moduli vengono sottoposte a rendering come moduli HTML, i pannelli non sono vincolati a una particolare dimensione di pagina. Se disponi di sottomaschere dinamiche, queste devono essere nidificate all’interno della sottomaschera del pannello. Le sottomaschere dinamiche possono espandersi fino a un numero infinito di pagine HTML.

Quando un modulo viene renderizzato come modulo HTML, le dimensioni della pagina (necessarie per impaginare i moduli renderizzati come PDF) non hanno alcun significato. Poiché un modulo con un layout scorrevole può essere espanso fino a un numero infinito di pagine HTML, è importante evitare i piè di pagina nella pagina master. Un piè di pagina sotto l'area del contenuto di una pagina master può sovrascrivere il contenuto HTML che passa oltre il limite di una pagina.

È necessario passare esplicitamente da un pannello all'altro utilizzando i metodi xfa.host.pageUp e xfa.host.pageDown. Per modificare le pagine, è necessario inviare un modulo al servizio Forms e fare in modo che il servizio Forms esegua nuovamente il rendering del modulo sul dispositivo client, in genere un browser Web.

.fsc-ds-ssb: questo foglio di stile è applicabile se è presente un campo del segno vuoto.

.fsc-ds-ssv: questo foglio di stile è applicabile se è presente un campo del segno valido.

.fsc-ds-ssc: questo foglio di stile è applicabile se è presente un campo Segno valido ma i dati sono stati modificati.

.fsc-ds-ssi: questo foglio di stile è applicabile se è presente un campo di firma non valido.

.fsc-ds-popup-bg: proprietà del foglio di stile non utilizzata.

.fsc-ds-popup-btn: proprietà del foglio di stile non utilizzata.

Esecuzione degli script running-scripts

Un autore di moduli specifica se uno script viene eseguito sul server o sul client. Il servizio Forms crea un ambiente di elaborazione degli eventi distribuito per l'esecuzione di informazioni sui moduli che può essere distribuito tra il client e il server utilizzando l'attributo runAt. Per informazioni su questo attributo o sulla creazione di script nelle progettazioni di moduli, vedere Forms Designer

Il servizio Forms può eseguire script durante il rendering del modulo. Di conseguenza, è possibile precompilare un modulo con i dati connettendosi a un database o a servizi Web che potrebbero non essere disponibili sul client. È inoltre possibile impostare l'evento Click di un pulsante da eseguire sul server in modo che il client esegua l'arrotondamento dei dati al server. Questo consente al client di eseguire script che potrebbero richiedere risorse server, ad esempio un database aziendale, mentre un utente interagisce con un modulo. Per i moduli HTML, gli script formcalc possono essere eseguiti solo sul server. È quindi necessario contrassegnare questi script per l'esecuzione alle server o both.

È possibile progettare moduli che si spostano tra pagine (pannelli) chiamando i metodi xfa.host.pageUp e xfa.host.pageDown. Questo script viene inserito nell'evento Click di un pulsante e l'attributo runAt è impostato su Both. Il motivo per cui si sceglie Both è che Adobe Reader o Acrobat (per i moduli di cui è stato eseguito il rendering come PDF) possono modificare le pagine senza passare al server e i moduli HTML possono modificare le pagine eseguendo il round tripping dei dati nel server. In altre parole, un modulo viene inviato al servizio Forms e un modulo viene riprodotto come HTML con la nuova pagina visualizzata.

È consigliabile non assegnare alle variabili di script e ai campi modulo gli stessi nomi, ad esempio item. Alcuni browser Web, ad esempio Internet Explorer, potrebbero non inizializzare una variabile con lo stesso nome di un campo modulo, causando un errore di script. È buona prassi assegnare nomi diversi ai campi modulo e alle variabili di script.

Quando si esegue il rendering di moduli HTML che contengono sia funzionalità di spostamento tra pagine che script di moduli (ad esempio, si supponga che uno script recuperi i dati di campo da un database ogni volta che viene eseguito il rendering del modulo), assicurarsi che lo script del modulo si trovi nell'evento form:calculal posto del form:readyevent.

Gli script di modulo presenti nell'evento form:ready vengono eseguiti una sola volta durante il rendering iniziale del modulo e non vengono eseguiti per i recuperi di pagina successivi. Al contrario, l’evento form:calculate viene eseguito per ogni navigazione della pagina in cui viene eseguito il rendering del modulo.

È possibile richiamare script personalizzati prima di inviare un modulo. Questa funzione funziona su tutti i browser disponibili. Tuttavia, può essere utilizzato solo quando gli utenti eseguono il rendering del modulo HTML la cui proprietà Output Type è impostata su Form Body. Non funzionerà quando Output Type è Full HTML. Per informazioni su come configurare questa funzione, consulta Configurazione dei moduli nella guida per l’amministrazione.

Definire innanzitutto una funzione di callback chiamata prima dell'invio del modulo, dove il nome della funzione è _user_onsubmit. Si presume che la funzione non genererà alcuna eccezione o, in caso contrario, l’eccezione verrà ignorata. Si consiglia di inserire la funzione JavaScript nella sezione head dell'html; tuttavia, è possibile dichiararla in qualsiasi punto prima della fine dei tag script che includono xfasubset.js.

Quando formserver esegue il rendering di un XDP che contiene un elenco a discesa, oltre a creare l’elenco a discesa, crea anche due campi di testo nascosti. Questi campi di testo memorizzano i dati dell’elenco a discesa (uno memorizza il nome visualizzato delle opzioni, l’altro il valore delle opzioni). Pertanto, ogni volta che un utente invia il modulo, vengono inviati tutti i dati dell’elenco a discesa. Supponendo di non voler inviare ogni volta una quantità di dati così elevata, puoi scrivere uno script personalizzato per disabilitarla. Ad esempio: il nome dell'elenco a discesa è drpOrderedByStateProv e viene racchiuso nell'intestazione del sottomodulo. Il nome dell'elemento di input HTML sarà header[0].drpOrderedByStateProv[0]. Il nome dei campi nascosti che memorizzano e inviano i dati del menu a discesa ha i seguenti nomi: header[0].drpOrderedByStateProv_DISPLAYITEMS_[0] header[0].drpOrderedByStateProv_VALUEITEMS_[0]

Se non desideri pubblicare i dati, puoi disattivare questi elementi di input nel modo seguente. var __CUSTOM_SCRIPTS_VERSION = 1; //enabling the feature function _user_onsubmit() { var elems = document.getElementsByName("header[0].drpOrderedByStateProv_DISPLAYITEMS_[0]"); elems[0].disabled = true; elems = document.getElementsByName("header[0].drpOrderedByStateProv_VALUEITEMS_[0]"); elems[0].disabled = true; }

header[0].drpOrderedByStateProv_DISPLAYITEMS_[0] header[0].drpOrderedByStateProv_VALUEITEMS_[0]

var __CUSTOM_SCRIPTS_VERSION = 1; //enabling the feature
    function _user_onsubmit() {
    var elems = document.getElementsByName("header[0].drpOrderedByStateProv_DISPLAYITEMS_[0]");
    elems[0].disabled = true;
    elems = document.getElementsByName("header[0].drpOrderedByStateProv_VALUEITEMS_[0]");
    elems[0].disabled = true;
    }

Sottoinsiemi XFA xfa-subsets

Durante la creazione di progettazioni di moduli da riprodurre come HTML, è necessario limitare gli script al sottoinsieme XFA per gli script in linguaggio JavaScript.

Gli script eseguiti sul client o sia sul client che sul server devono essere scritti all'interno del sottoinsieme XFA. Gli script eseguiti sul server possono utilizzare il modello di script XFA completo e anche FormCalc. Per informazioni sull'utilizzo di JavaScript, vedere Forms Designer.

Quando si eseguono gli script sul client, solo il pannello corrente visualizzato può utilizzare gli script; ad esempio, non è possibile eseguire script per i campi presenti nel pannello A quando viene visualizzato il pannello B. Durante l’esecuzione di script sul server, è possibile accedere a tutti i pannelli.

Prestare attenzione quando si utilizzano espressioni SOM (Scripting Object Model) all'interno di script eseguiti sul client. Solo un sottoinsieme semplificato di espressioni SOM è supportato dagli script eseguiti sul client.

Tempistica eventi event-timing

Il sottoinsieme XFA definisce gli eventi XFA mappati agli eventi HTML. C’è una leggera differenza di comportamento nella tempistica degli eventi di calcolo e convalida. In un browser web, un evento di calcolo completo viene eseguito quando esci da un campo. Gli eventi di calcolo non vengono eseguiti automaticamente quando si apporta una modifica al valore di un campo. È possibile forzare un evento di calcolo chiamando il metodo xfa.form.execCalculate.

In un browser web, gli eventi di convalida vengono eseguiti solo quando si esce da un campo o si invia un modulo. È possibile forzare un evento di convalida utilizzando il metodo xfa.form.execValidate.

I Forms visualizzati in un browser web (al contrario di Adobe Reader o Acrobat) sono conformi al test null XFA (errori o avvertenze) per i campi obbligatori.

Per ulteriori informazioni su un test null, vedere Forms Designer.

Pulsanti modulo form-buttons

Facendo clic su un pulsante Invia, i dati del modulo vengono inviati al servizio Forms e rappresentano la fine dell’elaborazione del modulo. L'evento preSubmit può essere impostato per l'esecuzione sul client o sul server. L'evento preSubmit viene eseguito prima dell'invio del modulo se è configurato per l'esecuzione sul client. In caso contrario, l'evento preSubmit viene eseguito sul server durante l'invio del modulo. Per ulteriori informazioni sull'evento preSubmit, vedere Forms Designer.

Se a un pulsante non è associato alcuno script sul lato client, i dati vengono inviati al server, i calcoli vengono eseguiti sul server e il modulo HTML viene rigenerato. Se un pulsante contiene uno script lato client, i dati non vengono inviati al server e lo script lato client viene eseguito nel browser Web.

Browser web HTML 4.0 html-4-0-web-browser

Un browser Web che supporta solo HTML 4.0 non può supportare il modello di script lato client del sottoinsieme XFA. Durante la creazione di una struttura di modulo da utilizzare sia in HTML 4.0 che in MSDHTML o CSS2HTML, uno script contrassegnato per l'esecuzione sul client verrà effettivamente eseguito sul server. Si supponga, ad esempio, che un utente faccia clic su un pulsante che si trova in un modulo visualizzato in un browser Web di HTML 4.0. In questa situazione, i dati del modulo vengono inviati al server in cui viene eseguito lo script lato client.

È consigliabile inserire la logica del modulo negli eventi di calcolo, che vengono eseguiti nel server di HTML 4.0 e nel client di MSDHTML o CSS2HTML.

Gestione delle modifiche alla presentazione maintaining-presentation-changes

Quando ci si sposta tra pagine HTML (pannelli), viene mantenuto solo lo stato dei dati. Impostazioni quali il colore di sfondo o le impostazioni obbligatorie dei campi non vengono mantenute (se diverse dalle impostazioni iniziali). Per mantenere lo stato di presentazione, è necessario creare campi, in genere nascosti, che rappresentano lo stato di presentazione dei campi. Se si aggiunge uno script all'evento Calculate di un campo che modifica la presentazione in base ai valori dei campi nascosti, è possibile mantenere lo stato di presentazione mentre si passa da una pagina HTML (pannelli) all'altra.

Lo script seguente mantiene fillColor di un campo in base al valore di hiddenField. Supponiamo che questo script si trovi nell'evento Calculate di un campo.

     If (hiddenField.rawValue == 1)
         this.fillColor = "255,0,0"
     else
         this.fillColor = "0,255,0"

Firma digitale di moduli HTML digitally-signing-html-forms

Non è possibile firmare un modulo HTML contenente un campo di firma digitale se il modulo viene sottoposto a rendering come una delle seguenti trasformazioni di HTML:

Per informazioni sulla firma digitale di un documento, vedere Firma digitale e certificazione di documenti

Rendering di un modulo XHTML conforme alle linee guida di accessibilità rendering-an-accessibility-guidelines-compliant-xhtml-form

È possibile eseguire il rendering di un modulo HTML completo conforme alle linee guida per l'accessibilità. In altre parole, il rendering del modulo viene eseguito all’interno di tag HTML completi, mentre il rendering del modulo HTML viene eseguito all’interno di tag body (non una pagina HTML completa).

Convalida dei dati del modulo validating-form-data

È consigliabile limitare l'utilizzo delle regole di convalida per i campi modulo durante il rendering del modulo come modulo HTML. Alcune regole di convalida potrebbero non essere supportate per i moduli HTML. Quando ad esempio viene applicato un modello di convalida MM-GG-AAAA a un campo Date/Time in una struttura di modulo di cui è stato eseguito il rendering come modulo HTML, il modello non funziona correttamente, anche se la data è stata digitata correttamente. Tuttavia, questo modello di convalida funziona correttamente per i moduli renderizzati come PDF.

Riepilogo dei passaggi summary-of-steps

Per eseguire il rendering di un modulo HTML, effettuare le seguenti operazioni:

Includi file di progetto

Includi i file necessari nel progetto di sviluppo. Se stai creando un’applicazione client utilizzando Java, includi i file JAR necessari. Se utilizzi i servizi web, accertati di includere i file proxy.

Creare un oggetto API client di Forms

Prima di poter importare i dati a livello di programmazione in un’API formClient di PDF, è necessario creare un client del servizio di integrazione dei dati dei moduli. Quando si crea un client di servizio, vengono definite le impostazioni di connessione necessarie per richiamare un servizio.

Imposta opzioni runtime di HTML

È possibile impostare le opzioni di runtime di HTML durante il rendering di un modulo di HTML. È possibile, ad esempio, aggiungere una barra degli strumenti a un modulo di HTML per consentire agli utenti di selezionare i file allegati presenti nel computer client o di recuperare i file allegati di cui è stato eseguito il rendering con il modulo di HTML. Per impostazione predefinita, la barra degli strumenti di HTML è disabilitata. Per aggiungere una barra degli strumenti a un modulo di HTML, è necessario impostare le opzioni di runtime a livello di programmazione. Per impostazione predefinita, una barra degli strumenti di HTML è costituita dai pulsanti riportati di seguito.

Quando in un modulo di HTML HTML viene visualizzata una barra degli strumenti, l’utente può selezionare un massimo di dieci file da inviare insieme ai dati del modulo. Una volta inviati i file, il servizio Forms può recuperarli.

Quando si esegue il rendering di un modulo come HTML, è possibile specificare un valore user-agent. Un valore user-agent fornisce informazioni sul browser e sul sistema. Questo è un valore facoltativo e puoi trasmettere un valore stringa vuoto. Il modulo Rendering di un HTML utilizzando l’avvio rapido API Java mostra come ottenere un valore agente utente e utilizzarlo per eseguire il rendering di un modulo come HTML.

Gli URL HTTP in cui vengono pubblicati i dati del modulo possono essere specificati impostando l’URL di destinazione utilizzando l’API client del servizio Forms oppure possono essere specificati nel pulsante Invia contenuto nella progettazione del modulo XDP. Se l’URL di destinazione è specificato nella progettazione del modulo, non impostare un valore utilizzando l’API client del servizio Forms.

Eseguire il rendering di un modulo HTML

Per eseguire il rendering di un modulo HTML, specifica una struttura di modulo creata in Designer e salvata come file XDP. Selezionare un tipo di trasformazione HTML. È ad esempio possibile specificare il tipo di trasformazione HTML che esegue il rendering di un HTML dinamico per Internet Explorer 5.0 o versione successiva.

Il rendering di un modulo HTML richiede anche valori, ad esempio valori URI necessari per il rendering di altri tipi di modulo.

Scrivere il flusso di dati del modulo nel browser Web client

Quando il servizio Forms esegue il rendering di un modulo HTML, restituisce un flusso di dati del modulo che è necessario scrivere nel browser Web client. Quando viene scritto nel browser Web del client, il modulo HTML è visibile all'utente.

Consulta anche

Eseguire il rendering di un modulo come HTML utilizzando l’API Java

Eseguire il rendering di un modulo come HTML utilizzando l’API del servizio web

Inclusione dei file della libreria Java di AEM Forms

Impostazione delle proprietà di connessione

Guida introduttiva all’API di servizio Forms

Rendering dei PDF forms interattivi

Rendering di HTML Forms con barre degli strumenti personalizzate

Creazione di applicazioni Web per il rendering di Forms

Eseguire il rendering di un modulo come HTML utilizzando l’API Java render-a-form-as-html-using-the-java-api

Eseguire il rendering di un modulo HTML utilizzando l’API Forms (Java):

Consulta anche

Rendering di Forms come HTML

Quick Start (modalità SOAP): rendering di un modulo HTML tramite l’API Java

Inclusione dei file della libreria Java di AEM Forms

Impostazione delle proprietà di connessione

Eseguire il rendering di un modulo come HTML utilizzando l’API del servizio web render-a-form-as-html-using-the-web-service-api

Eseguire il rendering di un modulo HTML utilizzando l’API Forms (servizio web):

Consulta anche

Rendering di Forms come HTML

Richiamare AEM Forms utilizzando la codifica Base64