Show Menu
ARGOMENTI×

Sviluppo di moduli (interfaccia classica)

La struttura di base di un modulo è la seguente:
  • Inizio modulo
  • Elementi modulo
  • Fine modulo
Tutti questi componenti sono realizzati con una serie di componenti predefiniti per moduli, disponibili in un’installazione standard di AEM.
Oltre a sviluppare nuovi componenti da utilizzare nei moduli, è anche possibile:
Uso degli script per estendere le funzionalità laddove necessario.
Questo documento si concentra sullo sviluppo di moduli utilizzando i componenti Componenti di base Foundation nell'interfaccia classica. Adobe consiglia di utilizzare i nuovi componenti introduction.html core e di nascondere le condizioni per lo sviluppo di moduli nell’interfaccia touch.

Precaricamento dei valori del modulo

Il componente Inizio modulo fornisce un campo per il Percorso di caricamento, un percorso facoltativo che punta a un nodo nell’archivio.
Percorso di caricamento è il percorso delle proprietà nodo utilizzato per caricare valori predefiniti in più campi del modulo.
Si tratta di un campo facoltativo, per specificare il percorso di un nodo nella directory archivio. Quando alcune proprietà di questo nodo corrispondono ai nomi dei campi, i relativi campi del modulo vengono precompilati con il valore della proprietà corrispondente. In assenza di proprietà corrispondenti, il campo contiene il valore predefinito.
Un'azione Sviluppo di azioni modulo personalizzate modulo può anche impostare la risorsa da cui caricare i valori iniziali. Questa operazione viene eseguita utilizzando FormsHelper#setFormLoadResource l'interno init.jsp .
Solo se non è impostato, l'autore compilerà il modulo dal percorso impostato nel componente Modulo iniziale.

Preloading Form Fields with Multiple Values

Vari campi modulo dispongono anche di Percorso di caricamento elementi, anch'esso un percorso facoltativo che punta a un nodo nella directory archivio.
Percorso di caricamento elementi è il percorso delle proprietà nodo utilizzato per caricare valori predefiniti in quel campo specifico del modulo, ad esempio un elenco a discesa, un gruppo di caselle di controllo o un gruppo di pulsanti di scelta.

Esempio: precaricamento di un elenco a discesa con più valori

Un elenco a discesa più essere configurato con una serie di valori da selezionare.
Il Percorso di caricamento degli elementi può essere utilizzato per accedere a un elenco da una cartella nella directory archivio e precaricarlo nel campo:
  1. Create a new sling folder ( sling:Folder )
    for example, /etc/designs/<myDesign>/formlistvalues
  2. Aggiungere una nuova proprietà (ad esempio, myList ) di tipo stringa con più valori ( String[] ) per contenere l'elenco di elementi a discesa. Il contenuto può essere importato anche utilizzando uno script, ad esempio con uno script JSP o cURL in uno script shell.
  3. Utilizzare il percorso completo nel campo Percorso di caricamento elementi :
    for example, /etc/designs/geometrixx/formlistvalues/myList
Se i valori in String[] sono formattati come segue:
  • AL=Alabama
  • AK=Alaska
  • etc.
AEM genererà l’elenco come:
  • <option value="AL">Alabama</option>
  • <option value="AK">Alaska</option>
Questa funzione può, ad esempio, essere utilizzata in un ambiente multilingue.

Sviluppo di azioni modulo personalizzate

Un modulo richiede un’azione Un'azione definisce l'operazione che viene eseguita quando il modulo viene inviato con i dati utente.
Con un’installazione standard di AEM sono disponibili diverse azioni, descritte di seguito:
/libs/foundation/components/form/actions
e nell’elenco Tipo ​azione del componente Modulo :
Questa sezione illustra come sviluppare un’azione per il modulo personalizzata da includere in questo elenco.
Puoi aggiungere la tua azione in /apps quanto segue:
  1. Creare un nodo di tipo sling:Folder . Specificate un nome che rifletta l’azione da implementare.
    Ad esempio:
    /apps/myProject/components/customFormAction
  2. In questo nodo definire le seguenti proprietà, quindi fare clic su Salva tutto per salvare le modifiche:
    • sling:resourceType - impostata come foundation/components/form/action
    • componentGroup - Definisci come .hidden
    • Facoltativamente:
      • jcr:title - specifica un titolo di tua scelta, che verrà visualizzato nell'elenco a discesa di selezione. Se non è impostato, viene visualizzato il nome del nodo
      • jcr:description - inserire una descrizione della scelta
  3. Nella cartella create un nodo di finestra di dialogo:
    1. Aggiungere i campi in modo che l'autore possa modificare la finestra di dialogo dei moduli una volta selezionata l'azione.
  4. Nella cartella create:
    1. Uno script di pubblicazione.
      Il nome dello script è post.POST.<extension> , ad esempio post.POST.jsp
      Lo script post viene richiamato quando un modulo viene inviato per elaborare il modulo, contiene il codice che gestisce i dati provenienti dal modulo POST .
    2. Aggiungere uno script in avanti che viene richiamato all'invio del modulo.
      Il nome dello script è forward.<extension >, ad esempio forward.jsp
      Questo script può definire un percorso. La richiesta corrente viene quindi inoltrata al percorso specificato. La chiamata necessaria è FormsHelper#setForwardPath (2 varianti). Un caso tipico consiste nell'eseguire alcune operazioni di convalida o logica per individuare il percorso di destinazione e quindi inoltrarlo a tale percorso, consentendo al servlet Sling POST predefinito di eseguire l'effettiva memorizzazione in JCR.
    Potrebbe anche esserci un altro servlet che esegue l'effettiva elaborazione, in tal caso l'azione del modulo e il forward.jsp quale agisce solo come il codice "colla". Un esempio di questo è l'azione di posta in /libs/foundation/components/form/actions/mail , che inoltra i dettagli a <currentpath>.mail.html dove si trova un servlet di posta.
    Quindi:
    • a post.POST.jsp è utile per le operazioni di piccole dimensioni che sono completamente eseguite dall'azione stessa
    • mentre forward.jsp è utile quando è richiesta solo la delega.
    L'ordine di esecuzione degli script è il seguente:
    • Al momento del rendering del modulo ( GET ):
      1. init.jsp
      2. per tutti i vincoli del campo: clientvalidation.jsp
      3. convalida del moduloRT: clientvalidation.jsp
      4. il modulo viene caricato tramite la risorsa di caricamento, se impostato
      5. addfields.jsp durante il rendering <form></form>
    • durante la gestione di un modulo POST :
      1. init.jsp
      2. per tutti i vincoli del campo: servervalidation.jsp
      3. convalida del moduloRT: servervalidation.jsp
      4. forward.jsp
      5. se è stato impostato un percorso avanti ( FormsHelper.setForwardPath ), inoltrate la richiesta, quindi chiamate cleanup.jsp
      6. se non è stato impostato alcun percorso in avanti, chiama post.POST.jsp (termina qui, non viene cleanup.jsp chiamato)
  5. Anche nella cartella aggiungete facoltativamente:
    1. Uno script per l'aggiunta di campi.
      Il nome dello script è addfields.<extension> , ad esempio addfields.jsp
      Uno script addfields viene richiamato subito dopo la scrittura dell'HTML per l'avvio del modulo. Questo consente di aggiungere campi di input personalizzati o altri elementi HTML di questo tipo all'interno del modulo.
    2. Uno script di inizializzazione.
      Il nome dello script è init.<extension> , ad esempio init.jsp
      Questo script viene richiamato quando si esegue il rendering del modulo. Può essere utilizzato per inizializzare specifiche delle azioni. ``
    3. Uno script di pulizia.
      Il nome dello script è cleanup.<extension> , ad esempio cleanup.jsp
      Questo script può essere utilizzato per eseguire la pulizia.
  6. Utilizzare il componente Moduli in un parsys. Il menu a discesa Tipo ​azione ora include la nuova azione.
    Per visualizzare le azioni predefinite che fanno parte del prodotto:
    /libs/foundation/components/form/actions

Sviluppo di vincoli di modulo personalizzati

I vincoli possono essere imposti a due livelli:

Vincoli per i singoli campi

È possibile aggiungere vincoli personalizzati per un singolo campo (in /apps ) come segue:
  1. Creare un nodo di tipo sling:Folder . Specificare un nome che rifletta il vincolo da implementare.
    Ad esempio:
    /apps/myProject/components/customFormConstraint
  2. In questo nodo definire le seguenti proprietà, quindi fare clic su Salva tutto per salvare le modifiche:
    • sling:resourceType - impostare foundation/components/form/constraint
    • constraintMessage - un messaggio personalizzato che verrà visualizzato se il campo non è valido, in base al vincolo, all'invio del modulo
    • Facoltativamente:
      • jcr:title - specifica un titolo di tua scelta, che verrà visualizzato nell'elenco di selezione. Se non è impostato, viene visualizzato il nome del nodo
      • hint - ulteriori informazioni, per l'utente, su come utilizzare il campo
  3. All'interno di questa cartella possono essere necessari i seguenti script:
    • Uno script di convalida client:
      Il nome dello script è clientvalidation.<extension> , ad esempio clientvalidation.jsp
      Viene richiamato quando viene eseguito il rendering del campo modulo. Può essere utilizzato per creare JavaScript client per convalidare il campo sul client.
    • Uno script di convalida server:
      Il nome dello script è servervalidation.<extension> , ad esempio servervalidation.jsp
      Viene richiamato all’invio del modulo. Può essere utilizzato per convalidare il campo sul server dopo l'invio.
I vincoli di esempio sono elencati di seguito:
/libs/foundation/components/form/constraints

Vincoli globali modulo

La convalida globale del modulo viene specificata configurando un tipo di risorsa nel componente Modulo iniziale ( validationRT ). Ad esempio:
apps/myProject/components/form/validation
Potete quindi definire:
  • a clientvalidation.jsp - inserito dopo gli script di convalida client del campo
  • e un servervalidation.jsp - chiamato anche dopo la convalida del singolo server di campi su un POST .

Showing and Hiding Form Components

È possibile configurare il modulo in modo da mostrare o nascondere i componenti in base al valore di altri campi del modulo.
La modifica della visibilità di un campo modulo è utile se il campo è richiesto solo in presenza di particolari condizioni. Ad esempio, in un modulo di feedback, può essere presente una domanda che chiede al cliente se desidera ricevere per e-mail informazioni sui prodotti. Se il cliente risponde Sì, compare un campo di testo per l’inserimento dell’indirizzo e-mail.
Use the Edit Show/Hide Rules dialog box to specify the conditions under which a form component is shown or hidden.
Utilizzate i campi nella parte superiore della finestra di dialogo per specificare le seguenti informazioni:
  • Se si specificano le condizioni per nascondere o mostrare il componente.
  • Se qualsiasi o tutte le condizioni devono essere soddisfatte per mostrare o nascondere il componente.
Una o più condizioni vengono visualizzate al di sotto di questi campi. Una condizione prevede il confronto del valore di un altro componente (dello tesso modulo) con un particolare valore. Se il valore effettivo inserito nel campo soddisfa la condizione, questa viene considerata true (vera). Le condizioni includono le seguenti informazioni:
  • Il Titolo del campo che si sta verificando.
  • Un operatore.
  • Un valore rispetto al quale viene confrontato il valore del campo.
Ad esempio, un componente Gruppo pulsanti di scelta con il titolo Receive email notifications? * * contiene Yes e No pulsanti di scelta. A Text Field component with the title of Email Address uses the following condition so that it is visible if Yes is selected:
In Javascript, per fare riferimento ai campi, nelle condizioni viene utilizzato il valore della proprietà Nome elemento. In the previous example, the Element Name property of the Radio Group component is contact . Il seguente codice rappresenta il codice JavaScript per questo esempio:
((contact == "Yes"))
Per visualizzare o nascondere un componente modulo:
  1. Modificare il componente modulo specifico.
  2. Selezionate Mostra/Nascondi per aprire la finestra di dialogo Modifica Mostra/Nascondi regole :
    • Nel primo elenco a discesa, selezionare Mostra o Nascondi per specificare se le condizioni determinano se mostrare o nascondere il componente.
    • Nell'elenco a discesa alla fine della riga superiore, seleziona:
      • all - se tutte le condizioni devono essere soddisfatte per mostrare o nascondere il componente
      • qualsiasi - se solo una o più condizioni devono essere soddisfatte per mostrare o nascondere il componente
    • Nella riga condizione (una è presentata come impostazione predefinita), selezionate un componente, un operatore e specificate un valore.
    • Se necessario, aggiungere altre condizioni facendo clic su Aggiungi condizione .
    Ad esempio:
  3. Click OK to save the definition.
  4. After you saved your definition, an Edit Rules link appears next to the Show / Hide option in the form component properties. Click this link to open the Edit Show / Hide Rules dialog box to make changes.
    Click OK to save all changes.
    Gli effetti delle definizioni Mostra/Nascondi possono essere visti e testati:
    • in modalità Anteprima nell’ambiente di authoring (per passare all’anteprima, è necessario ricaricare la pagina)
    • sull’ambiente di pubblicazione

Handling Broken Component References

Per le condizioni mostra/nascondi viene utilizzato il valore della proprietà Nome elemento per fare riferimento ad altri componenti del modulo. La configurazione Mostra/Nascondi non è valida se una delle condizioni fa riferimento a un componente eliminato o la cui proprietà Nome elemento è stata modificata. Se si verifica questa situazione, è necessario aggiornare manualmente le condizioni; in caso contrario si verificherà un errore durante il caricamento del modulo.
Se la configurazione Mostra/Nascondi non è valida, la configurazione viene fornita solo come codice JavaScript. Modificate il codice per correggere i problemi. Nel codice viene usata la proprietà Nome elemento impostata originariamente per fare riferimento ai componenti.

Sviluppo di script da utilizzare con Forms

Per ulteriori informazioni sugli elementi API utilizzabili per la scrittura di script, vedere le javadocs correlate ai moduli .
È possibile utilizzare questa opzione per azioni quali la chiamata di un servizio prima dell'invio del modulo e l'annullamento del servizio in caso di errore:
  • Definire il tipo di risorsa di convalida
  • Includere uno script per la convalida:
    • In JSP, richiamare il servizio Web e creare un oggetto com.day.cq.wcm.foundation.forms.ValidationInfo contenente i messaggi di errore. Se si verificano degli errori, i dati del modulo non verranno inviati.