Architettura dei moduli di HTML5 architecture-of-html-forms
Architettura architecture
La funzionalità di HTML5 Forms viene distribuita come pacchetto all'interno dell'istanza AEM incorporata ed è esposta come endpoint REST su HTTP/S utilizzando RESTful Apache Sling Architecture.
Utilizzo di Sling Framework using-sling-framework
Apache Sling è incentrato sulle risorse. Utilizza un URL di richiesta per risolvere prima la risorsa. Ogni risorsa ha una proprietà sling:resourceType (o sling:resourceSuperType). In base a questa proprietà, al metodo di richiesta e alle proprietà dell’URL della richiesta, viene quindi selezionato uno script sling per gestire la richiesta. Questo script sling può essere un JSP o un servlet. Per i moduli HTML5, i nodi Profile fungono da risorse sling e Profile Renderer funge da script sling che gestisce la richiesta di rendering del modulo mobile con un profilo specifico. Un modulo di rendering profili è una JSP che legge i parametri da una richiesta e chiama il servizio Forms OSGi.
Per informazioni dettagliate sull'endpoint REST e sui parametri di richiesta supportati, vedere Rendering del modello di modulo.
Quando un utente effettua una richiesta da un dispositivo client come un browser iOS o Android™, Sling risolve prima il nodo del profilo in base all’URL della richiesta. Da questo nodo profilo vengono letti sling:resourceSuperType e sling:resourceType per determinare tutti gli script disponibili che possono gestire questa richiesta di rendering del modulo. Quindi utilizza i selettori di richieste Sling insieme al metodo di richiesta per identificare lo script più adatto per la gestione di questa richiesta. Una volta che la richiesta raggiunge una JSP di rendering del profilo, JSP chiama il servizio OSGi di Forms.
Per ulteriori dettagli sulla risoluzione dello script Sling, vedi Scheda di riferimento rapido Sling AEM o Scomposizione URL Sling Apache.
Flusso di chiamata di elaborazione modulo tipico typical-form-processing-call-flow
I moduli HTML5 memorizzano nella cache tutti gli oggetti intermedi necessari per elaborare (rendering o invio) un modulo alla prima richiesta. Non memorizza in cache gli oggetti dipendenti dai dati, in quanto tali oggetti potrebbero cambiare.
Mobile Form mantiene due diversi livelli di cache, PreRender cache e Render cache. La cache di preRender contiene tutti i frammenti e le immagini di un modello risolto, mentre la cache di rendering contiene contenuto renderizzato come HTML.
Flusso di lavoro per moduli di HTML5
I moduli HTML5 non memorizzano in cache i modelli con riferimenti mancanti di frammenti e immagini. Se i moduli di HTML5 richiedono più tempo del normale, controlla i registri del server per individuare eventuali riferimenti e avvisi mancanti. Verificare inoltre che non venga raggiunta la dimensione massima dell'oggetto.
Il servizio OSGi di Forms elabora una richiesta in due passaggi:
- Generazione dello stato del layout e del modulo iniziale: il servizio di rendering OSGi di Forms chiama il componente Cache di Forms per determinare se il modulo è già stato memorizzato nella cache e non è stato invalidato. Se il modulo è memorizzato nella cache ed è valido, viene distribuito dalla cache al HTML generato. Se il modulo viene invalidato, il servizio di rendering Forms OSGi genera il layout modulo iniziale e lo stato del modulo in formato XML. Questo XML viene trasformato in layout HTML e stato iniziale del modulo JSON dal servizio Forms OSGi e quindi memorizzato nella cache per le richieste successive.
- Forms precompilato: durante il rendering, se un utente richiede moduli con dati precompilati, il servizio di rendering OSGi di Forms chiama il contenitore del servizio Forms e genera un nuovo stato del modulo con dati uniti. Tuttavia, poiché il layout è già generato nel passaggio precedente, questa chiamata è più veloce della prima chiamata. Questa chiamata esegue solo l’unione dei dati ed esegue gli script sui dati.
Se nel modulo sono presenti aggiornamenti o risorse utilizzate all’interno del modulo, il componente Cache modulo lo rileva e la cache per quel particolare modulo viene invalidata. Una volta completata l’elaborazione da parte del servizio OSGi di Forms, JSP aggiunge al modulo i riferimenti e lo stile della libreria JavaScript e restituisce la risposta al client. Un server Web tipico come Apache può essere utilizzato qui con compressione HTML attivata. Un server web ridurrebbe in modo significativo le dimensioni della risposta, il traffico di rete e il tempo necessario per lo streaming dei dati tra server e computer client.
Quando un utente invia il modulo, il browser invia lo stato del modulo in formato JSON al proxy del servizio submit; il proxy del servizio di invio genera un XML dati utilizzando i dati JSON e invia tale XML dati all'endpoint di invio.
Componenti components
Per abilitare HTML Forms è necessario il pacchetto del componente aggiuntivo AEM Forms. Per informazioni sull'installazione del pacchetto del componente aggiuntivo AEM Forms, vedere Installazione e configurazione di AEM Forms.
Componenti OSGi (adobe-lc-forms-core.jar) osgi-components-adobe-lc-forms-core-jar
Adobe XFA Forms Renderer (com.adobe.livecycle.adobe-lc-forms-core) è il nome visualizzato del bundle OSGi HTML5 forms visualizzato dalla visualizzazione bundle di Felix Admin Console (https://[host]:[porta]/system/console/bundles).
Questo componente contiene componenti OSGi per le impostazioni di rendering, gestione della cache e configurazione.
Servizio Forms OSGi forms-osgi-service
Questo servizio OSGi contiene la logica per il rendering di un XDP come HTML e gestisce l’invio di un modulo per generare l’XML dei dati. Questo servizio utilizza il contenitore del servizio Forms. Il contenitore del servizio Forms chiama internamente il componente nativo XMLFormService.exe che esegue l'elaborazione.
Se viene ricevuta una richiesta di rendering, questo componente chiama il contenitore del servizio Forms per generare informazioni su layout e stato che vengono ulteriormente elaborate per generare gli stati DOM dei moduli HTML e JSON.
Questo componente è anche responsabile della generazione di dati XML da JSON dello stato del modulo inviato.
Componente cache cache-component
HTML5 forms utilizza la memorizzazione nella cache per ottimizzare la velocità effettiva e i tempi di risposta. Puoi configurare il livello del servizio cache per ottimizzare il compromesso tra prestazioni e utilizzo dello spazio.
I moduli HTML5 eseguono il caching in memoria utilizzando la strategia LRU. Se la strategia della cache è impostata su Nessuno, la cache non verrà creata e i dati esistenti, se presenti, verranno cancellati. Oltre alla strategia di caching, puoi anche configurare la dimensione totale della cache in memoria, che può essere utile per avere la dimensione massima associata alla cache e, se va oltre, utilizzerà la modalità LRU per liberare le risorse della cache.
Servizio di configurazione configuration-service
Configuration Service consente di ottimizzare i parametri di configurazione e le impostazioni della cache per i moduli HTML5.
Per aggiornare queste impostazioni, vai all'Admin Console CQ Felix (disponibile all'indirizzo https://<'[server]:[porta]'/system/console/configMgr), cerca e seleziona Configurazione Forms mobile.
Puoi configurare la dimensione della cache o disabilitarla utilizzando il servizio di configurazione. È inoltre possibile abilitare il debug utilizzando il parametro Opzioni di debug. Ulteriori informazioni sul debug dei moduli sono disponibili in Debug dei moduli di HTML5.
Componenti runtime (adobe-lc-forms-runtime-pkg.zip) runtime-components-adobe-lc-forms-runtime-pkg-zip
Il pacchetto runtime contiene le librerie lato client utilizzate per eseguire il rendering dei moduli HTML.
Componenti importanti disponibili come parte del pacchetto runtime:
Motore di script scripting-engine
L’implementazione XFA di Adobe supporta due tipi di linguaggi di script per consentire l’esecuzione logica definita dall’utente nei moduli: JavaScript e FormCalc.
Il motore di script di HTML Forms è scritto in JavaScript per supportare l’API di script XFA in entrambi questi linguaggi.
Al momento del rendering, lo script FormCalc viene tradotto (e memorizzato nella cache) in JavaScript sul server in modo trasparente per l’utente o la finestra di progettazione.
Questo motore di script utilizza alcune funzionalità di ECMAScript5 come Object.defineProperty. Il motore o la libreria viene distribuito come libreria client CQ con il nome di categoria xfaforms.profile. Fornisce inoltre l'API FormBridge per consentire l'interazione di applicazioni o portali esterni con il modulo. Utilizzando FormBridge, un'app esterna può nascondere alcuni elementi a livello di programmazione, ottenerne o impostarne i valori o modificarne gli attributi.
Per ulteriori dettagli, vedere l'articolo Bridge del modulo.
Motore di layout layout-engine
Il layout e l’aspetto visivo dei moduli HTML5 si basano sulle funzioni SVG 1.1, jQuery, BackBone e CSS3. L’aspetto iniziale di un modulo viene generato e memorizzato nella cache del server. La modifica del layout iniziale e le ulteriori modifiche incrementali al layout del modulo vengono gestite sul client. Per ottenere questo risultato, il pacchetto Runtime contiene un motore di layout scritto in JavaScript e basato su jQuery/Backbone. Questo motore gestisce tutti i comportamenti dinamici, ad esempio Aggiungi/Rimuovi istanze ripetibili, layout di oggetti di crescita. Questo motore di layout esegue il rendering di un modulo una pagina alla volta. Inizialmente, un utente visualizza solo una pagina e la barra di scorrimento orizzontale tiene conto solo della prima pagina. Tuttavia, quando un utente scorre verso il basso, inizia il rendering della pagina successiva. Questa rappresentazione pagina per pagina riduce il tempo necessario per il rendering della prima pagina in un browser e migliora le prestazioni percepite del modulo. Questo motore/libreria fa parte della libreria client CQ con il nome di categoria xfaforms.profile.
Il motore di layout contiene anche un set di widget utilizzati per acquisire il valore dei campi modulo da un utente. Questi widget sono modellati come jQuery UI Widget che implementano alcuni contratti aggiuntivi per funzionare senza problemi con il motore di layout.
Per ulteriori dettagli sui widget e i contratti corrispondenti, vedere Widget personalizzati per moduli HTML5.
Attribuzione stile styling
Lo stile associato agli elementi HTML viene aggiunto in linea o in base al blocco CSS incorporato. Alcuni stili comuni che non dipendono dalla forma fanno parte della libreria client CQ con il nome di categoria xfaforms.profile.
Oltre alle proprietà di stile predefinite, ogni elemento modulo contiene alcune classi CSS basate su tipo di elemento, nome e altre proprietà. Utilizzando queste classi, è possibile ridefinire gli elementi specificando il proprio CSS.
Per ulteriori dettagli sugli stili e le classi predefiniti, vedere Introduzione agli stili.
Script lato server e servizi Web server-side-script-and-web-services
Tutti gli script contrassegnati per l'esecuzione sul server o per la chiamata a un servizio Web (indipendentemente dalla posizione in cui è contrassegnato per l'esecuzione) vengono sempre eseguiti sul server.
Il motore di script client:
- Effettua una chiamata sincrona al server passando lo stato corrente del modulo sotto forma di JSON
- Esegue lo script o il servizio Web sul server
- Genera un nuovo stato JSON
- Unisce il nuovo stato JSON sul client quando viene restituita la risposta.
Bundle risorse di localizzazione localization-resource-bundles
I moduli HTML5 supportano la lingua italiana (it), spagnola (es), portoghese brasiliano (pt_BR), cinese semplificato (zh_CN), cinese tradizionale (solo supporto limitato) (zh_TW), coreana (ko_KR), inglese (en_US), francese (fr_FR), tedesca (de_DE) e giapponese (ja). In base alle impostazioni locali ricevute nell’intestazione della richiesta, il Bundle di risorse corrispondente viene inviato al client. Questo bundle di risorse viene aggiunto a JSP profilo come libreria client CQ con nome categoria xfaforms.I18N. È possibile ignorare la logica di prelievo del pacchetto delle impostazioni internazionali nel profilo.
Componenti Sling (adobe-lc-forms-content-pkg.zip) sling-components-adobe-lc-forms-content-pkg-zip
Il pacchetto Sling contiene contenuti relativi a Profili e Profile Renderer.
Profili profiles
I profili sono i nodi Resource in Sling che rappresentano un modulo o una famiglia di Forms. A livello CQ, questi profili sono nodi JCR. I nodi si trovano nella cartella /content nell'archivio JCR e possono trovarsi in qualsiasi sottocartella della cartella /content.
Rendering profilo profile-renderers
Il nodo Profilo ha una proprietà sling:resourceSuperType con valore xfaforms/profile. Questa proprietà invia internamente le richieste di inoltro allo script sling per i nodi di profilo nella cartella /libs/xfaforms/profile. Si tratta di pagine JSP, che sono contenitori per la creazione di moduli HTML e di artefatti JS/CSS richiesti. Le pagine includono riferimenti a:
- xfaforms.I18N.<impostazioni locali>: questa libreria contiene dati localizzati.
- xfaforms.profile: questa libreria contiene l'implementazione per il motore di script e layout XFA.
Queste librerie sono modellate come librerie client CQ e sfruttano i vantaggi della concatenazione automatica, della minimizzazione e della compressione delle librerie JavaScript del framework CQ.
Per ulteriori informazioni sulle librerie client CQ, consulta la documentazione Clientlib CQ.
Come descritto in precedenza, il modulo di rendering del profilo JSP chiama il servizio Forms tramite un’inclusione sling. Questa JSP imposta anche varie opzioni di debug in base alla configurazione amministratore o ai parametri di richiesta.
I moduli di HTML5 consentono agli sviluppatori di creare un profilo e un modulo di rendering dei profili per personalizzare l’aspetto dei moduli. I moduli HTML, ad esempio, consentono agli sviluppatori di integrare i moduli in un pannello o in una sezione <div> di un portale HTML esistente.
Per ulteriori dettagli sulla creazione di profili personalizzati, vedere Creazione di un profilo personalizzato.