Creazione di moduli HTML

Quando una struttura del modulo contiene sottomoduli che si espandono, è difficile prevedere con esattezza il numero delle pagine contenute nel modulo risultante in fase di esecuzione. Le impostazioni relative alle dimensioni delle pagine vengono utilizzate per impaginare i moduli PDF, ma vengono ignorate durante il rendering di un modulo HTML, perché le pagine HTML possono avere qualsiasi lunghezza.

Per implementare un modulo HTML con più pagine, è possibile includere nella struttura del modulo un sottomodulo a livello di singola pagina. Sarà necessario un sottomodulo di questo tipo per ogni pagina di cui si desidera eseguire il rendering nel modulo. Per i moduli con layout fluido, ogni sottomodulo che produce contenuto deve essere nidificato all'interno di uno dei sottomoduli a livello di pagina. In seguito, quando si esegue il rendering del modulo, tutti i contenuti relativi allo stesso sottomodulo verranno visualizzati nella stessa pagina HTML.

Ad esempio, osservare la struttura del modulo presentata nella seguente illustrazione. La struttura del modulo include tre sottomoduli a livello di pagina: Subform_Page0, Subform_Page1 e Subform_LastPage. Se Forms dovesse eseguire il rendering di un modulo HTML basato su questa struttura del modulo, verrebbe automaticamente creata una pagina HTML per ogni sottomodulo a livello di pagina.

A.

Il sottomodulo Subform_Page0 posiziona il contenuto ed è impostato per visualizzare gli oggetti che lo compongono sulla prima pagina del modulo, utilizzando il layout della pagina master Page1.

B.

Il sottomodulo Subform_Page1 contiene un sottomodulo con contenuto scorrevole. Il sottomodulo Expanding_subform può ripetere il rendering dei propri oggetti ogni volta che risulta necessario in seguito all'unione dei dati. Il contenuto del sottomodulo Subform_Page1 può essere visualizzato su una o più pagine utilizzando il layout della pagina master Page2_etc.

C.

Il sottomodulo Subform_LastPage posiziona il contenuto ed è impostato in modo da visualizzare i propri oggetti nell'ultima pagina visualizzata, utilizzando il layout della pagina master Page3.

Quando Forms esegue il rendering del modulo HTML in fase di esecuzione, il primo sottomodulo a livello di pagina viene visualizzato nella prima pagina. Nel caso dell'esempio, la prima pagina avrà un aspetto simile a quello illustrato di seguito. Osservare il pulsante Pagina successiva, che deve essere incluso per consentire agli utenti di passare alla pagina successiva del modulo.

Presupponendo che sia disponibile almeno un record da unire a Expanding_subform in fase di esecuzione, la seconda pagina avrà un aspetto simile a quello illustrato di seguito. Anche in questo caso, è necessario includere il pulsante Pagina successiva per consentire agli utenti di passare alla pagina successiva del modulo. È possibile scegliere di includere anche un pulsante Pagina Precedente nel modulo personalizzato.

Il terzo sottomodulo a livello di pagina (Subform_LastPage) viene visualizzato sull'ultima pagina del modulo di cui si esegue il rendering. In questo esempio, l'ultima pagina contiene un messaggio di ringraziamento per gli utenti che hanno compilato il modulo e un pulsante di invio che consente di inviare a Forms i dati immessi dall'utente.

Per informazioni sulla creazione di uno script che consenta agli utenti di spostarsi tra le pagine HTML, vedere Come creare uno script per gestire le pagine HTML.

Le informazioni seguenti possono essere utili per creare moduli HTML esteticamente gradevoli e facili da leggere:

• Non utilizzare le proprietà relative al bordo degli oggetti per disegnare righe, riquadri o griglie all'interno del modulo. In alcuni browser i bordi non vengono allineati esattamente come nell'anteprima di Designer. Gli oggetti possono risultare sovrapposti o impedire di visualizzare altri oggetti nella posizione prevista.

• Se il modulo deve essere visualizzato con Microsoft Internet Explorer, è possibile utilizzare righe, rettangoli e cerchi per definire lo sfondo. Tutti gli altri browser Web supportano solamente righe verticali e orizzontali; pertanto, i rettangoli e i cerchi eventualmente disegnati sulla struttura del modulo non verranno visualizzati in fase di esecuzione.

• Se gli utenti utilizzano browser Opera, le dimensioni dei campi dovranno essere leggermente più grandi del previsto, poiché in Opera i campi hanno sempre un bordo interno rientrato. Qualsiasi stile di bordo sarà applicato intorno al lato esterno del bordo. Poiché il bordo rientrato occupa spazio all'interno del campo, l'area che può essere effettivamente utilizzata risulta più piccola.

• Anche le dimensioni del testo statico devono essere leggermente più grandi di quelle necessarie per contenere il testo. Designer e Acrobat possono utilizzare una crenatura diversa da quella di un particolare browser Web e alcuni testi potrebbero non essere visualizzati correttamente.

Quando si aggiungono immagini a strutture del modulo da visualizzare in formato HTML, è consigliabile tenere conto delle linee guida seguenti.

File di immagine supportati

È possibile includere qualsiasi file di immagine (ad eccezione dei file GIF animati), tenendo conto delle limitazioni dei browser Web utilizzati dagli utenti per visualizzare i moduli HTML.

Nota: Tenere presente che in Internet Explorer la combinazione di oggetto pulsante e immagine viene elaborata in modo differente rispetto ad altri browser Web. Ad esempio, se si crea un oggetto pulsante con un aspetto trasparente personalizzato e lo si posiziona sopra un oggetto immagine, l'esecuzione del rendering HTML risultante in Internet Explorer potrebbe rendere il pulsante inaccessibile tramite clic. Vedere Come aggirare i limiti dei browser Web.

Non incorporare immagini nel modulo

Forms non supporta le immagini incorporate. Utilizzare invece percorsi relativi per inserire i file di immagine. Ad esempio, il percorso può essere relativo alla directory principale dei moduli di Forms che, per impostazione predefinita, corrisponde alla cartella indicata come archivio dei moduli. Nel percorso seguente la cartella delle immagini si trova sullo stesso livello della cartella dei moduli:

../images/graphic.jpg

Se si presume che alcuni utenti utilizzino browser con capacità limitate, è necessario considerarne i limiti e progettare i moduli in base alle funzioni minime supportate da tali browser. In alternativa, se nella propria azienda vengono utilizzati browser che supportano XHTML, per progettare il layout della struttura del modulo sarà possibile scegliere tra più opzioni.

Quando si progettano moduli da visualizzare con tipi di browser diversi, tenere presente le considerazioni seguenti:

• Specificare un formato di pagina tale da garantire che la trasformazione HTML4 (per Netscape Navigator 4.7.x) visualizzi correttamente tutti gli oggetti statici. In caso contrario, durante il rendering del modulo verrà riservato solo lo spazio necessario per i campi.

• Incorporare un margine di almeno 0,65 cm (0,25 pollici) sui lati superiore e sinistro del modulo. Tutti gli elementi che si trovano sopra o a sinistra di tale margine non verranno visualizzati.

• Gli oggetti o parti di oggetti tracciati in corrispondenza delle coordinate negative della griglia non vengono visualizzati. Se ad esempio si disegna un oggetto a partire dalla coordinata verticale -0,50 della griglia, la parte dell’oggetto compresa tra la coordinata 0,50 e il bordo interno del margine da 0,65 cm (0,25 pollici) non verrà visualizzata.

• Lasciare spazio sufficiente intorno ai campi per compensare la deformazione visiva che si potrebbe verificare in un browser di livello inferiore. Ad esempio, in alcuni browser le dimensioni delle caselle di controllo e dei pulsanti di scelta sono maggiori rispetto a quelle previste in fase di progettazione.

• Se si utilizza un browser di basso livello per visualizzare il modulo, l'allineamento a sinistra dei dati potrebbe non essere mantenuto, soprattutto se l'utente modifica i font predefiniti associati al browser utilizzato.

• In Internet Explorer la combinazione di oggetto pulsante e immagine viene elaborata in modo differente rispetto ad altri browser Web. Ad esempio, se si crea un oggetto pulsante con un aspetto trasparente personalizzato e lo si posiziona sopra un oggetto immagine, l'esecuzione del rendering HTML risultante in Internet Explorer potrebbe rendere il pulsante inaccessibile tramite clic. Tuttavia, è possibile selezionare il pulsante con il tasto Tab e sostituire il clic di conferma con la pressione del tasto Invio o della Barra Spaziatrice. Questo errore di elaborazione si verifica perché la dimensione dell'oggetto pulsante dipende dalla lunghezza della relativa didascalia. Le dimensioni dell'area della didascalia devono essere tali da consentire al pulsante di estendersi oltre il contorno dell'immagine. Per risolvere il problema, inserire nell'area della didascalia un numero di spazi vuoti sufficiente per estendere il pulsante oltre il contorno dell'immagine e consentire agli utenti di fare clic su di esso.

Per verificare il corretto funzionamento della struttura del modulo con Forms e impostare con precisione i pulsanti di comando di una struttura del modulo, è necessario conoscere l'URL che verrà associato alle richieste in Forms. Lo sviluppatore dell'applicazione personalizzata deve conoscere tale URL.

Per visualizzare l'anteprima di un modulo HTML, la struttura del modulo deve essere resa disponibile per Forms, affinché possa archiviarla. In seguito sarà possibile richiedere il modulo tramite l'URL associato a Forms. Aprire il modulo con un browser Web o con una delle applicazioni client di destinazione, ad esempio un assistente vocale.

È possibile incorporare calcoli e script in una struttura del modulo per eseguire calcoli, metodi oppure operazioni durante la verifica di qualsiasi evento dell'oggetto in fase di esecuzione. Ad esempio, un evento si verifica in fase di runtime quando l'utente esegue l'azione cui corrisponde l'evento. È possibile richiamare uno dei metodi supportati dall'oggetto ed esaminare o impostare delle proprietà definendo uno script.

Per impostazione predefinita, in Designer gli script e i calcoli sono destinati all'esecuzione sul dispositivo client. Il percorso di elaborazione predefinito viene specificato nella scheda Anteprima della finestra di dialogo Proprietà modulo (selezionare File > Proprietà modulo). Per sostituire il percorso di elaborazione predefinito, quando si allega uno script o un calcolo a un oggetto è possibile specificare in modo esplicito un percorso di elaborazione diverso, utilizzando l'opzione Esegui su nell'Editor di script.

Se si dispone di Forms, è possibile elaborare i dati sul client, sul server o su entrambi. Quando si specifica che uno script/calcolo deve essere eseguito su client e server, il client e il server possono entrambi tentare l'esecuzione dello script/del calcolo. Forms esegue sempre un tentativo di elaborazione dello script o del calcolo se il client non è in grado di farlo. Se si specifica l'esecuzione di script/calcoli sul server, Forms esegue gli script e/o i calcoli, riunisce i risultati nel modulo e restituisce entrambi al client.

Gli script e i calcoli sul lato client sono eseguiti sulla periferica client. Quando si creano dei moduli PDF per Acrobat o Adobe Reader, tutte le elaborazioni devono essere eseguite sul client. Se tuttavia il client non è in grado di eseguire lo script o il calcolo, Forms tenterà di effettuarne l'elaborazione.

Per eseguire correttamente uno script sul lato client in un modulo HTML, è necessario rispettare alcune condizioni.

• L'applicazione client deve essere Microsoft Internet Explorer 5.x, Netscape 6.0 o versione successiva oppure Opera 5 o versione successiva.

• È possibile utilizzare JavaScript solo per la creazione degli script (non è possibile includere calcoli di FormCalc nella struttura del modulo).

• È necessario che nell'applicazione client sia abilitato JavaScript.

L'elaborazione può avvenire sul client, sul server o su entrambi. Il funzionamento degli script e dei calcoli varia a seconda che siano eseguiti sul client o sul server.

Se si intende utilizzare una singola struttura del modulo per creare moduli PDF e HTML, gli script potranno fare riferimento ad un sottoinsieme di proprietà, metodi ed eventi.

Le tabelle seguenti contengono un riepilogo delle applicazioni client che riconoscono le varie proprietà, i metodi e gli eventi cui è possibile fare riferimento negli script sul lato client e sul lato server.

Nota 1: per le caselle di riepilogo, formattedValue non restituisce il testo da visualizzare.

Nota 2: l'evento clic non è supportato per i pulsanti di invio nei moduli PDF o HTML. Utilizzare invece l'evento preSubmit

Nota 3: l'oggetto ScriptObject può essere creato e utilizzato con qualsiasi altro script. VedereCreazione di un oggetto di script.

Nota 1: per le caselle di riepilogo, formattedValue non restituisce il testo da visualizzare.

Nota 2: l'evento clic non è supportato per i pulsanti di invio nei moduli PDF. Utilizzare invece l'evento preSubmit

Nota 3: l'oggetto ScriptObject può essere creato e utilizzato con qualsiasi altro script. VedereCreazione di un oggetto di script.

I client HTML supportano un sottoinsieme semplificato di espressioni di sintassi di riferimento:

• I calcoli di FormCalc non sono validi nei browser HTML e vengono rimossi prima che venga eseguito il rendering del modulo in formato HTML.

• La sintassi con puntini di sospensione (...) non è supportata.

• Quando si crea uno script lato client per i moduli HTML, è necessario utilizzare l'espressione JavaScript resolveNode per indicare la posizione dei nodi nella gerarchia. Lo script non può attraversare la gerarchia utilizzando la notazione dell'oggetto. Ad esempio, la seguente espressione non è supportata:

      xfa.form.subform1.TextEdit1

La seguente espressione è invece supportata:

xfa.form.resolveNode("subform1.TextEdit1")

Per individuare i campi di pari livello all'interno della gerarchia è possibile utilizzare riferimenti di campo non qualificati.

Quando si utilizza la stessa struttura del modulo per eseguire il rendering di moduli PDF e HTML, le impostazioni relative alle dimensioni di pagina vengono utilizzate per impaginare i moduli PDF, ma vengono ignorate durante il rendering dei moduli HTML. Per gestire le differenze tra le pagine PDF e HTML, gli autori dei moduli possono utilizzare sottomoduli a livello di pagina per definire pagine HTML artificiali. Quando la pagine HTML sono impostate in questo modo, per consentire agli utenti di spostarsi da una pagina HTML alla successiva in fase di esecuzione è necessario creare il codice JavaScript appropriato.

È possibile utilizzare i metodi pageUp() e pageDown() per consentire agli utenti di spostarsi tra le pagine HTML, utilizzando un pulsante di comando regolare che avvia l'elaborazione quando si verifica l'evento clic del pulsante. Per i moduli PDF e HTML l'elaborazione deve essere eseguita sul client e sul server.

I metodi pageUp() e pageDown() operano sui sottomoduli a livello di pagina. Ad esempio, si supponga che l'autore del modulo abbia impostato la struttura seguente all'interno della struttura del modulo:

A.

Questo sottomodulo a livello di pagina corrisponde alla prima pagina.

B.

Questo sottomodulo a livello di pagina corrisponde alla seconda pagina.

C.

Questo sottomodulo a livello di pagina corrisponde alla terza pagina.

Se l’utente visualizzasse la pagina HTML corrispondente al sottomodulo Subform_Page0, il richiamo di xfa.host.pageDown() comporterebbe la visualizzazione del sottomodulo Subform_Page1 nel browser. Allo stesso modo, il richiamo di xfa.host.pageUp() quando è visualizzato il sottomodulo Subform_Page1 determinerebbe la visualizzazione del sottomodulo Subform_Page0 sul browser. Per la manipolazione di queste pagine HTML, i numeri di pagina devono essere assegnati alle seguenti proprietà:

xfa.host.currentPage = 0     //moves to the first page 
xfa.host.currentPage = 1     //moves to the second page 
xfa.host.currentPage = 2     //moves to the third page 
xfa.host.currentPage = xfa.host.numPages -1     //moves to the last page

Quando gli utenti si spostano tra le pagine HTML lo stato dei dati viene mantenuto, ma lo stato di presentazione di un oggetto (ad esempio il colore dello sfondo di un campo) può variare da una pagina all'altra. Per mantenere le impostazioni di presentazione tra le pagine è possibile utilizzare campi nascosti che contengono i valori di stato delle varie impostazioni e pulsanti di comando che consentono agli utenti di passare alla pagina precedente o successiva del modulo. Lo script deve aggiornare gli stati di presentazione dei campi in base ai valori contenuti nei campi nascosti. Quando l'utente fa clic su uno qualsiasi dei pulsanti di comando, l'evento di calcolo corrispondente al pulsante può essere utilizzato per l'esecuzione dello script.

Ad esempio, il codice JavaScript seguente mantiene il colore di riempimento di un campo in base al valore di un campo denominato hiddenField (campo nascosto). Lo script viene avviato quando si verifica l'evento calculate.

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