AEM 6.4 ha raggiunto la fine del supporto esteso e questa documentazione non viene più aggiornata. Per maggiori dettagli, consulta la nostra periodi di assistenza tecnica. Trova le versioni supportate qui.
Quando si inizia a sviluppare nuovi componenti è necessario comprendere le nozioni di base della loro struttura e configurazione.
Questo processo comporta la lettura della teoria e l'analisi dell'ampia gamma di implementazioni di componenti in un'istanza AEM standard. Quest’ultimo approccio è leggermente complicato dal fatto che, sebbene AEM sia passato a una nuova interfaccia utente standard, moderna e touch, continua a supportare l’interfaccia classica.
Questa sezione descrive i concetti e i problemi chiave come introduzione ai dettagli necessari allo sviluppo dei tuoi componenti.
Prima di iniziare effettivamente a configurare o codificare il componente, è necessario chiedere:
Cosa devi fare esattamente con il nuovo componente?
Una specifica chiara aiuta in tutte le fasi di sviluppo, test e consegna.
I dettagli possono cambiare nel tempo, ma la specifica può essere aggiornata (anche se le modifiche devono essere documentate).
È necessario creare un componente da zero o è possibile ereditare le nozioni di base da un componente esistente?
Il componente richiederà una logica per selezionare/manipolare il contenuto?
Il componente avrà bisogno della formattazione CSS?
Quali aspetti di sicurezza devo prendere in considerazione?
Prima di iniziare una discussione seria sullo sviluppo di componenti è necessario sapere quale interfaccia utente utilizzeranno gli autori:
Interfaccia touch
Interfaccia utente standard introdotto in AEM 5.6.0 come anteprima ed esteso in 6.x. Si basa sull’esperienza utente unificata di Adobe Marketing Cloud, utilizzando le tecnologie di base di Interfaccia Coral e Interfaccia Granite.
Interfaccia classica
Interfaccia utente basata sulla tecnologia ExtJS introdotta con CQ 5.1.
Vedi Interfaccia utente Recommendations per clienti per ulteriori dettagli.
I componenti possono essere implementati per supportare l’interfaccia touch, l’interfaccia classica o entrambe. Quando osservi un’istanza standard, vengono anche visualizzati i componenti predefiniti originariamente progettati per l’interfaccia classica, l’interfaccia touch o entrambi.
Per questo motivo descriveremo le nozioni di base di entrambi e come riconoscerli in questa pagina.
Adobe consiglia di utilizzare l’interfaccia touch per sfruttare le tecnologie più recenti. Strumenti di modernizzazione AEM può semplificare la migrazione.
Si consiglia di mantenere il codice responsabile del markup e del rendering separato dal codice che controlla la logica utilizzata per selezionare il contenuto del componente.
Questa filosofia è sostenuta da HTL, un linguaggio di template appositamente limitato per garantire un linguaggio di programmazione reale viene utilizzato per definire la logica di business sottostante. Questa logica (facoltativa) viene richiamata da HTL con un comando specifico. Questo meccanismo evidenzia il codice richiesto per una determinata visualizzazione e, se necessario, consente una logica specifica per diverse visualizzazioni dello stesso componente.
HTL è un linguaggio per modelli HTML introdotto con AEM 6.0.
La discussione sull'utilizzo HTL o JSP (Java Server Pages) quando si sviluppano i propri componenti deve essere semplice, in quanto HTL è ora il linguaggio di script consigliato per AEM.
HTL e JSP possono essere utilizzati per lo sviluppo di componenti sia per l’interfaccia classica che per quella touch. Anche se si può presumere che HTL sia solo per l’interfaccia touch e JSP per l’interfaccia classica, si tratta di un’errata concezione e più a causa dei tempi. L’interfaccia touch e HTL sono stati incorporati in AEM per circa lo stesso periodo. Poiché HTL è ora la lingua consigliata, viene utilizzato per i nuovi componenti, che tendono a essere per l’interfaccia touch.
Le eccezioni sono i campi modulo di base dell’interfaccia utente Granite (utilizzati nelle finestre di dialogo). Questi richiedono ancora l'utilizzo di JSP.
Per creare componenti personalizzati per l’interfaccia utente appropriata, consulta (dopo aver letto questa pagina):
Un modo rapido per iniziare consiste nel copiare un componente esistente e quindi apportare le modifiche desiderate. Per informazioni su come creare i propri componenti e aggiungerli al sistema paragrafo, consulta:
I componenti che eseguono il rendering del contenuto devono essere distribuiti nella stessa istanza AEM del contenuto. Pertanto, tutti i componenti utilizzati per l’authoring e il rendering delle pagine nell’istanza di authoring devono essere distribuiti nell’istanza di pubblicazione. Quando vengono distribuiti, i componenti sono disponibili per il rendering delle pagine attivate.
Utilizza i seguenti strumenti per spostare i componenti nell’istanza di pubblicazione:
Questi meccanismi possono essere utilizzati anche per trasferire il componente tra altre istanze, ad esempio dallo sviluppo all’istanza di test.
Pagina:
cq:Page
).Sistemi paragrafo:
parsys
, [responsivegrid](/docs/experience-manager-64/sites-authoring/responsive-layout.md)
).La struttura di un componente AEM è potente e flessibile, le principali considerazioni sono:
Un elemento chiave della struttura è il tipo di risorsa.
Questa è un'astrazione che aiuta a garantire che anche quando l'aspetto e l'aspetto cambiano nel tempo, l'intenzione rimanga nel tempo.
La definizione di un componente può essere suddivisa come segue:
I componenti AEM sono basati su Sling.
I componenti AEM si trovano in genere in:
/libs/wcm/foundation/components
/libs/foundation/components
I componenti specifici per progetto/sito si trovano (in genere) in:
/apps/<myApp>/components
AEM componenti standard sono definiti come cq:Component
e hanno gli elementi chiave:
proprietà jcr:
Un elenco delle proprietà di jcr; queste sono variabili e alcune possono essere facoltative anche se la struttura di base di un nodo componente, le sue proprietà e i suoi sottonodi sono definiti da cq:Component
definizione
Riferimenti:
Definiscono gli elementi statici utilizzati dal componente.
Script:
Vengono utilizzati per implementare il comportamento dell’istanza risultante del componente.
Nodo principale:
<mycomponent> (cq:Component)
- Nodo gerarchico del componente.Proprietà vitali:
jcr:title
- Titolo del componente; ad esempio, utilizzato come etichetta quando il componente è elencato nel browser o nella barra laterale dei componenti.
jcr:description
- Descrizione del componente; può essere utilizzato come hint di passaggio del mouse nel browser componenti o nella barra laterale.
Interfaccia classica:
icon.png
- Icona per questo componente.thumbnail.png
- Immagine mostrata se questo componente è elencato all’interno del sistema paragrafo.Interfaccia utente touch
Nodi figlio fondamentali:
cq:editConfig (cq:EditConfig)
- Definisce le proprietà di modifica del componente e consente al componente di essere visualizzato nel browser Componenti o nella barra laterale.
Nota: se il componente dispone di una finestra di dialogo, viene visualizzato automaticamente nel browser Componenti o nella barra laterale, anche se cq:editConfig non esiste.
cq:childEditConfig (cq:EditConfig)
- Controlla gli aspetti dell’interfaccia utente dell’autore per i componenti secondari che non definiscono i propri cq:editConfig
.
Interfaccia touch:
cq:dialog
( nt:unstructured
) - Finestra di dialogo per questo componente. Definisce l’interfaccia che consente all’utente di configurare il componente e/o modificare il contenuto.cq:design_dialog
( nt:unstructured
) - Modifica di progettazione per questo componenteInterfaccia classica:
dialog
( cq:Dialog
) - Finestra di dialogo per questo componente. Definisce l’interfaccia che consente all’utente di configurare il componente e/o modificare il contenuto.design_dialog
( cq:Dialog
): modifica di progettazione per questo componente.L’icona o l’abbreviazione del componente viene definita tramite le proprietà JCR del componente quando il componente viene creato dallo sviluppatore. Queste proprietà vengono valutate nell'ordine seguente e viene utilizzata la prima proprietà valida trovata.
cq:icon
- Proprietà di stringa che punta a un'icona standard nel Libreria dell’interfaccia utente Coral da visualizzare nel browser componenti
abbreviation
- Proprietà String per personalizzare l'abbreviazione del nome del componente nel browser componenti
L'abbreviazione deve essere limitata a due caratteri.
Specificando una stringa vuota verrà generata l'abbreviazione dei primi due caratteri del jcr:title
proprietà.
L’abbreviazione viene tradotta solo se il componente ha una abbreviation_commentI18n
, che viene quindi utilizzato come hint di traduzione.
cq:icon.png
o cq:icon.svg
- Icona per questo componente, visualizzata nel browser Componenti
20 x 20 pixel è la dimensione delle icone dei componenti standard.
Il colore consigliato è rgb(112, 112, 112) > #707070
Lo sfondo delle icone dei componenti standard è trasparente.
Solo .png
e .svg
i file sono supportati.
Se si importa dal file system tramite il plugin Eclipse, i nomi dei file devono essere preceduti da _cq_icon.png
o _cq_icon.svg
ad esempio.
.png
sostituisce .svg
se sono presenti entrambi
Se nessuna delle proprietà di cui sopra ( cq:icon
, abbreviation
, cq:icon.png
o cq:icon.svg
) si trovano sul componente:
sling:resourceSuperType
proprietà.jcr:title
del componente corrente.Per annullare l’ereditarietà di icone da super componenti, impostare un valore vuoto abbreviation
sul componente viene ripristinato il comportamento predefinito.
La Console Componenti mostra come è definita l’icona di un particolare componente.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" x="0px" y="0px"
width="20px" height="20px" viewBox="0 0 20 20" enable-background="new 0 0 20 20" xml:space="preserve">
<ellipse cx="5" cy="5" rx="3" ry="3" fill="#707070"/>
<ellipse cx="15" cy="5" rx="4" ry="4" fill="#707070"/>
<ellipse cx="5" cy="15" rx="5" ry="5" fill="#707070"/>
<ellipse cx="15" cy="15" rx="4" ry="4" fill="#707070"/>
</svg>
Molti dei nodi/proprietà necessari per definire un componente sono comuni a entrambe le interfacce, con differenze che rimangono indipendenti in modo che il componente possa funzionare in entrambi gli ambienti.
Un componente è un nodo di tipo cq:Component
e dispone delle seguenti proprietà e nodi secondari:
Nome |
Tipo |
Descrizione |
. |
cq:Component |
Componente corrente. Un componente è di tipo nodo cq:Component . |
componentGroup |
String |
Gruppo in cui è possibile selezionare il componente nel browser Componenti (interfaccia touch) o nella barra laterale (interfaccia classica). Un valore di .hidden viene utilizzato per i componenti che non sono disponibili per la selezione dall’interfaccia utente, ad esempio i sistemi paragrafo effettivi. |
cq:isContainer |
Boolean |
Indica se il componente è un componente contenitore e può quindi contenere altri componenti, ad esempio un sistema paragrafo. |
cq:dialog |
nt:unstructured |
Definizione della finestra di dialogo di modifica per l’interfaccia touch. |
dialog |
cq:Dialog |
Definizione della finestra di dialogo di modifica per l’interfaccia classica. |
cq:design_dialog |
nt:unstructured |
Definizione della finestra di dialogo di progettazione per l’interfaccia touch. |
design_dialog |
cq:Dialog |
Definizione della finestra di dialogo di progettazione per l’interfaccia classica. |
dialogPath |
String |
Percorso di una finestra di dialogo che copre il caso in cui il componente non ha un nodo di dialogo. |
cq:cellName |
String |
Se impostata, questa proprietà viene presa come ID cella. Per ulteriori informazioni, consulta l’articolo della Knowledge Base Come vengono costruiti gli ID delle celle di progettazione. |
cq:childEditConfig |
cq:EditConfig |
Quando il componente è un contenitore, come ad esempio un sistema paragrafo, questa guida la configurazione di modifica dei nodi figlio. |
cq:editConfig |
cq:EditConfig |
Modifica la configurazione del componente. |
cq:htmlTag |
nt:unstructured |
Restituisce attributi di tag aggiuntivi aggiunti al tag HTML circostante. Abilita l’aggiunta di attributi ai div generati automaticamente. |
cq:noDecoration |
Boolean |
Se true, non viene eseguito il rendering del componente con classi div e css generate automaticamente. |
cq:template |
nt:unstructured |
Se trovato, questo nodo verrà utilizzato come modello di contenuto quando il componente viene aggiunto dal browser Componenti o dalla barra laterale. |
cq:templatePath |
String |
Percorso di un nodo da utilizzare come modello di contenuto quando il componente viene aggiunto dal browser Componenti o dalla barra laterale. Deve essere un percorso assoluto, non relativo al nodo del componente. A meno che non si desideri riutilizzare il contenuto già disponibile altrove, questo non è necessario e cq:template è sufficiente (vedi di seguito). |
jcr:created |
Date |
Data di creazione del componente. |
jcr:description |
String |
Descrizione del componente. |
jcr:title |
String |
Titolo del componente. |
sling:resourceSuperType |
String |
Quando è impostato, il componente eredita da questo componente. |
virtual |
sling:Folder |
Abilita la creazione di componenti virtuali. Per vedere un esempio, si prega di guardare il componente di contatto in:/libs/foundation/components/profile/form/contact |
<breadcrumb.jsp> |
nt:file |
File di script. |
icon.png |
nt:file |
L’icona del componente viene visualizzata accanto al titolo nella barra laterale. |
thumbnail.png |
nt:file |
Miniatura opzionale mostrata mentre il componente viene trascinato nella posizione desiderata dalla barra laterale. |
Se guardiamo al Testo in una delle due versioni, sono disponibili i seguenti elementi:
HTL ( /libs/wcm/foundation/components/text
)
JSP ( /libs/foundation/components/text
)
Le proprietà di particolare interesse comprendono:
jcr:title
- titolo del componente; può essere utilizzato per identificare il componente, ad esempio, viene visualizzato nell’elenco dei componenti all’interno del browser Componenti o della barra laterale
jcr:description
- descrizione del componente; può essere utilizzato come hint di passaggio del mouse nell’elenco dei componenti nella barra laterale
sling:resourceSuperType
: indica il percorso di ereditarietà quando si estende un componente (ignorando una definizione)
I nodi figlio di particolare interesse includono:
cq:editConfig
( cq:EditConfig
) - controlla gli aspetti visivi; ad esempio, può definire l'aspetto di una barra o di un widget, oppure può aggiungere controlli personalizzati
cq:childEditConfig
( cq:EditConfig
): controlla gli aspetti visivi dei componenti secondari privi di proprie definizioni
Interfaccia touch:
cq:dialog
( nt:unstructured
): definisce la finestra di dialogo per la modifica del contenuto di questo componentecq:design_dialog
( nt:unstructured
) - specifica le opzioni di modifica della progettazione per questo componenteInterfaccia classica:
dialog
( cq:Dialog
): definisce la finestra di dialogo per la modifica del contenuto di questo componente (specifica dell’interfaccia classica)design_dialog
( cq:Dialog
) - specifica le opzioni di modifica della progettazione per questo componenteicon.png
- file grafico da usare come icona per il componente nella barra lateralethumbnail.png
- file grafico da usare come miniatura del componente durante il trascinamento dalla barra lateraleLe finestre di dialogo sono un elemento chiave del componente, in quanto forniscono un’interfaccia che consente agli autori di configurare e fornire input a tale componente.
A seconda della complessità del componente, potrebbe essere necessaria una o più schede per mantenere breve la finestra di dialogo e per ordinare i campi di input.
Le definizioni delle finestre di dialogo sono specifiche dell’interfaccia utente:
Interfaccia touch
cq:dialog
( nt:unstructured
) nodi:
definire la finestra di dialogo per la modifica del contenuto di questo componente
specifica per l’interfaccia touch
sono definiti utilizzando i componenti dell’interfaccia Granite
hanno una proprietà sling:resourceType
, come struttura di contenuto Sling standard
può avere una proprietà helpPath
per definire la risorsa della guida sensibile al contesto (percorso assoluto o relativo) a cui si accede quando si utilizza l’icona della Guida ( ? (icona).
helpPath
viene specificato, viene visualizzato l’URL predefinito (pagina di panoramica della documentazione).All’interno della finestra di dialogo, vengono definiti i singoli campi:
Interfaccia classica
dialog
( cq:Dialog
) nodes
definire la finestra di dialogo per la modifica del contenuto di questo componente
specifiche dell’interfaccia classica
sono definiti utilizzando i widget ExtJS
hanno una proprietà xtype
, che si riferisce a ExtJS
può avere una proprietà helpPath
per definire la risorsa della guida sensibile al contesto (percorso assoluto o relativo) a cui si accede quando Aiuto è selezionato.
helpPath
viene specificato, viene visualizzato l’URL predefinito (pagina di panoramica della documentazione).All’interno della finestra di dialogo, vengono definiti i singoli campi:
In una finestra di dialogo classica:
cq:Dialog
, che fornisce una singola scheda - come nel componente testo, o se hai bisogno di più schede, come nel componente textimage, la finestra di dialogo può essere definita come cq:TabPanel
.cq:WidgetCollection
( items
) viene utilizzata per fornire una base per entrambi i campi di input ( cq:Widget
) o ulteriori schede ( cq:Widget
). Questa gerarchia può essere estesa.Le finestre di dialogo di progettazione sono molto simili alle finestre di dialogo utilizzate per modificare e configurare i contenuti, ma forniscono agli autori l’interfaccia per configurare e fornire dettagli di progettazione per quel componente.
Le finestre di dialogo di progettazione sono disponibili in modalità Progettazione, anche se non sono necessarie per tutti i componenti, ad esempio Titolo e Immagine entrambi hanno finestre di dialogo di progettazione, mentre Testo No.
La finestra di dialogo Progettazione per il sistema paragrafo (ad esempio, parsys) è un caso particolare in quanto consente all’utente di selezionare altri componenti specifici (dal browser Componenti o dalla barra laterale) nella pagina.
Una volta definito un componente, questo deve essere reso disponibile per l’uso. Per rendere un componente disponibile per l’uso in un sistema paragrafo, potete effettuare le seguenti operazioni:
Apri Modalità Progettazione per una pagina e abilita il componente richiesto.
Aggiungi i componenti richiesti al components
proprietà della definizione del modello in:
/etc/designs/<*yourProject*>/jcr:content/<*yourTemplate*>/par
Ad esempio, vedi:
/etc/designs/geometrixx/jcr:content/contentpage/par
Se creiamo e configuriamo un'istanza del Titolo nella pagina: <content-path>/Prototype.html
Interfaccia touch
Interfaccia classica
A questo punto è possibile vedere la struttura del contenuto creato all’interno dell’archivio:
In particolare, se si guarda il testo effettivo per un Titolo:
la definizione (per entrambe le interfacce) presenta la proprietà name
= ./jcr:title
/libs/foundation/components/title/cq:dialog/content/items/column/items/title
/libs/foundation/components/title/dialog/items/title
all’interno del contenuto, genera la proprietà jcr:title
contenuto dell'autore.
Le proprietà definite dipendono dalle singole definizioni. Anche se possono essere più complessi di quanto sopra, seguono comunque gli stessi principi di base.
I componenti all’interno di AEM sono soggetti a 3 gerarchie diverse:
Gerarchia dei tipi di risorsa
Viene utilizzato per estendere i componenti utilizzando la proprietà sling:resourceSuperType
. Questo consente al componente di ereditare. Ad esempio, un componente testo erediterà vari attributi dal componente standard.
Gerarchia dei contenitori
Viene utilizzato per popolare le impostazioni di configurazione per il componente figlio ed è utilizzato più comunemente in uno scenario parsys.
Ad esempio, le impostazioni di configurazione per i pulsanti della barra di modifica, il layout del set di controllo (barre di modifica, rollover), il layout della finestra di dialogo (in linea, mobile) possono essere definiti sul componente principale e propagati ai componenti secondari.
Impostazioni di configurazione (relative alla funzionalità di modifica) in cq:editConfig
e cq:childEditConfig
sono propagati.
Includi gerarchia
Questo viene imposto in fase di runtime dalla sequenza di "include".
Questa gerarchia è utilizzata da Designer, che a sua volta funge da base per vari aspetti di progettazione del rendering; tra cui informazioni sul layout, informazioni css, i componenti disponibili in un parsys tra gli altri.
Questa sezione spiega come configurare il comportamento di modifica di un componente. Ciò include attributi come le azioni disponibili per il componente, le caratteristiche dell’editor locale e i listener relativi agli eventi sul componente.
La configurazione è comune sia all’interfaccia touch che all’interfaccia classica, anche se con alcune specifiche differenze.
Il comportamento di modifica di un componente viene configurato aggiungendo un cq:editConfig
nodo di tipo cq:EditConfig
sotto il nodo del componente (di tipo cq:Component
) e aggiungendo proprietà specifiche e nodi secondari. Sono disponibili le seguenti proprietà e nodi figlio:
cq:actions
( String array
): definisce le azioni che possono essere eseguite sul componente.
cq:layout
( String
): : definisce la modalità di modifica del componente nell’interfaccia classica.
cq:dialogMode
( String
): definisce le modalità di apertura della finestra di dialogo dei componenti nell’interfaccia classica
cq:emptyText
( String
): definisce il testo che viene visualizzato quando non è presente alcun contenuto visivo.
cq:inherit
( Boolean
): definisce se i valori mancanti vengono ereditati dal componente da cui eredita.
dialogLayout
(Stringa): definisce come deve essere aperta la finestra di dialogo.
cq:dropTargets
(tipo di nodo) nt:unstructured
): definisce un elenco di destinazioni di rilascio che possono accettare un rilascio da una risorsa di Content Finder
cq:actionConfigs
(tipo di nodo) nt:unstructured
): definisce un elenco di nuove azioni che vengono aggiunte all’elenco cq:actions .
cq:formParameters
(tipo di nodo) nt:unstructured
): definisce parametri aggiuntivi aggiunti al modulo di dialogo.
cq:inplaceEditing
(tipo di nodo) cq:InplaceEditingConfig
): definisce una configurazione di modifica locale per il componente.
cq:listeners
(tipo di nodo) cq:EditListenersConfig
): definisce cosa accade prima o dopo un’azione sul componente.
In questa pagina, un nodo (proprietà e nodi secondari) è rappresentato come XML, come mostrato nell'esempio seguente.
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[edit]"
cq:dialogMode="floating"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig">
<cq:listeners
jcr:primaryType="cq:EditListenersConfig"
afteredit="REFRESH_PAGE"/>
</jcr:root>
Nell’archivio sono presenti molte configurazioni esistenti. È possibile cercare facilmente proprietà specifiche o nodi secondari:
Per cercare una proprietà del cq:editConfig
nodo, ad esempio cq:actions
, puoi utilizzare lo strumento Query in CRXDE Lite e cerca con la seguente stringa di query XPath:
//element(cq:editConfig, cq:EditConfig)[@cq:actions]
Per cercare un nodo figlio di cq:editConfig
, ad esempio puoi cercare cq:dropTargets
, che è di tipo cq:DropTargetConfig
; puoi utilizzare lo strumento Query in CRXDE Lite e cercare con la seguente stringa di query XPath:
//element(cq:dropTargets, cq:DropTargetConfig)
I componenti devono sempre eseguire il rendering di alcuni HTML visibili all’autore, anche quando il componente non ha contenuto. In caso contrario, potrebbe scomparire visivamente dall’interfaccia dell’editor, rendendola tecnicamente presente ma invisibile sulla pagina e nell’editor. In tal caso, gli autori non potranno selezionare e interagire con il componente vuoto.
Per questo motivo, i componenti devono eseguire il rendering di un segnaposto purché non rendano alcun output visibile quando la pagina viene sottoposta a rendering nell’editor di pagine (quando la modalità WCM è edit
o preview
).
Il markup tipico di HTML per un segnaposto è il seguente:
<div class="cq-placeholder" data-emptytext="Component Name"></div>
Lo script HTL tipico che esegue il rendering del segnaposto HTML di cui sopra è il seguente:
<div class="cq-placeholder" data-emptytext="${component.properties.jcr:title}"
data-sly-test="${(wcmmode.edit || wcmmode.preview) && isEmpty}"></div>
Nell'esempio precedente, isEmpty
è una variabile che è true solo quando il componente non ha contenuto ed è invisibile all’autore.
Per evitare ripetizioni, l’Adobe consiglia agli implementatori di componenti di utilizzare un modello HTL per questi segnaposto, come quello fornito dai componenti core.
L’utilizzo del modello nel collegamento precedente viene quindi fatto con la seguente riga di HTL:
<sly data-sly-use.template="core/wcm/components/commons/v1/templates.html"
data-sly-call="${template.placeholder @ isEmpty=!model.text}"></sly>
Nell'esempio precedente, model.text
è la variabile che è true solo quando il contenuto ha contenuto ed è visibile.
Un esempio di utilizzo di questo modello può essere visualizzato nei componenti core, come nel componente Titolo .
La cq:actions
proprietà ( String array
) definisce una o più azioni che possono essere eseguite sul componente. Per la configurazione sono disponibili i seguenti valori:
Valore proprietà | Descrizione |
text:<some text> |
Visualizza il valore del testo statico <some text=""> Visibile solo nell’interfaccia classica. L’interfaccia touch non visualizza le azioni in un menu contestuale, pertanto non è applicabile. |
- | Aggiunge un distanziatore. Visibile solo nell’interfaccia classica. L’interfaccia touch non visualizza le azioni in un menu contestuale, pertanto non è applicabile. |
edit |
Aggiunge un pulsante per modificare il componente. |
editannotate |
Aggiunge un pulsante per modificare il componente e consentire annotazioni. |
delete |
Aggiunge un pulsante per eliminare il componente |
insert |
Aggiunge un pulsante per inserire un nuovo componente prima di quello corrente |
copymove |
Aggiunge un pulsante per copiare e tagliare il componente. |
Nella configurazione seguente vengono aggiunti un pulsante di modifica, un distanziatore, un pulsante di eliminazione e un pulsante di inserimento alla barra di modifica del componente:
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[edit,-,delete,insert]"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig"/>
Nella configurazione seguente viene aggiunto il testo "Configurazioni ereditate dal framework di base" alla barra di modifica del componente:
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[text:Inherited Configurations from Base Framework]"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig"/>
La cq:layout
proprietà ( String
) definisce come modificare il componente nell’interfaccia classica. Sono disponibili i seguenti valori:
Valore proprietà | Descrizione |
rollover |
Valore predefinito. L’edizione del componente è accessibile "al passaggio del mouse" tramite clic e/o menu di scelta rapida. Per un uso avanzato, tieni presente che l’oggetto lato client corrispondente è: CQ.wcm.EditRollover . |
editbar |
L’edizione dei componenti è accessibile tramite una barra degli strumenti. Per un uso avanzato, tieni presente che l’oggetto lato client corrispondente è: CQ.wcm.EditBar . |
auto |
La scelta viene lasciata al codice lato client. |
I concetti di rollover e barra di modifica non sono applicabili nell’interfaccia touch.
Nella configurazione seguente viene aggiunto un pulsante di modifica alla barra di modifica del componente:
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[edit]"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig">
</jcr:root>
Il componente può essere collegato a una finestra di dialogo di modifica. La cq:dialogMode
proprietà ( String
) definisce le modalità di apertura della finestra di dialogo dei componenti nell’interfaccia classica. Sono disponibili i seguenti valori:
Valore proprietà | Descrizione |
floating |
La finestra di dialogo è mobile. |
inline |
(valore predefinito). La finestra di dialogo viene ancorata al componente. |
auto |
Se la larghezza del componente è inferiore al lato client CQ.themes.wcm.EditBase.INLINE_MINIMUM_WIDTH la finestra di dialogo è mobile, altrimenti è in linea. |
Nell’interfaccia touch, le finestre di dialogo sono sempre mobili in modalità desktop e vengono automaticamente aperte a schermo intero in dispositivi mobili.
La configurazione seguente definisce una barra di modifica con un pulsante di modifica e una finestra di dialogo mobile:
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
cq:actions="[edit]"
cq:dialogMode="floating"
cq:layout="editbar"
jcr:primaryType="cq:EditConfig">
</jcr:root>
La cq:emptyText
proprietà ( String
) definisce il testo visualizzato quando non è presente alcun contenuto visivo. Per impostazione predefinita: Drag components or assets here
.
La cq:inherit
proprietà ( boolean
) definisce se i valori mancanti vengono ereditati dal componente da cui eredita. Per impostazione predefinita false
.
La dialogLayout
La proprietà definisce come aprire una finestra di dialogo per impostazione predefinita.
fullscreen
apre la finestra di dialogo a schermo intero.La cq:dropTargets
nodo (tipo nodo) nt:unstructured
) definisce un elenco di destinazioni di rilascio che possono accettare un rilascio da una risorsa trascinata da Content Finder. Funge da raccolta di nodi di tipo cq:DropTargetConfig
.
Le destinazioni di rilascio multiple sono disponibili solo nell’interfaccia classica.
Nell’interfaccia touch verrà utilizzata solo la prima destinazione.
Ogni nodo figlio di tipo cq:DropTargetConfig
definisce un target di rilascio nel componente. Il nome del nodo è importante perché deve essere utilizzato nel JSP, come segue, per generare il nome della classe CSS assegnato all'elemento DOM che è il target di rilascio effettivo:
<drop target css class> = <drag and drop prefix> +
<node name of the drop target in the edit configuration>
La <*drag and drop prefix*>
è definito dalla proprietà Java :
com.day.cq.wcm.api.components.DropTarget.CSS_CLASS_PREFIX
.
Ad esempio, il nome della classe è definito come segue nel JSP del componente Download
( /libs/foundation/components/download/download.jsp
), dove file
è il nome del nodo della destinazione di rilascio nella configurazione di modifica del componente Download:
String ddClassName = DropTarget.CSS_CLASS_PREFIX + "file";
Il nodo di tipo cq:DropTargetConfig
deve avere le seguenti proprietà:
Nome proprietà | Valore proprietà |
accept |
Regex applicato al tipo di MIME della risorsa per convalidare se è consentito il rilascio. |
groups |
Array di gruppi di destinazione di rilascio. Ogni gruppo deve corrispondere al tipo di gruppo definito nell’estensione Content Finder e allegato alle risorse. |
propertyName |
Nome della proprietà che verrà aggiornata dopo un rilascio valido. |
La seguente configurazione viene presa dal componente Scarica . Abilita qualsiasi risorsa (il tipo mime può essere una stringa qualsiasi) dal media
gruppo da rilasciare da Content Finder al componente. Dopo il rilascio, la proprietà del componente fileReference
è in corso l'aggiornamento:
<cq:dropTargets jcr:primaryType="nt:unstructured">
<file
jcr:primaryType="cq:DropTargetConfig"
accept="[.*]"
groups="[media]"
propertyName="./fileReference"/>
</cq:dropTargets>
La cq:actionConfigs
nodo (tipo nodo) nt:unstructured
) definisce un elenco di nuove azioni aggiunte all’elenco definito dalla cq:actions
proprietà. Ogni nodo figlio di cq:actionConfigs
definisce una nuova azione definendo un widget.
La seguente configurazione di esempio definisce un nuovo pulsante (con un separatore per l’interfaccia classica):
un separatore, definito dall'xtype tbseparator
;
un pulsante denominato Gestire i commenti che esegue la funzione handler CQ_collab_forum_openCollabAdmin()
.
<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0"
cq:actions="[EDIT,COPYMOVE,DELETE,INSERT]"
jcr:primaryType="cq:EditConfig">
<cq:actionConfigs jcr:primaryType="nt:unstructured">
<separator0
jcr:primaryType="nt:unstructured"
xtype="tbseparator"/>
<manage
jcr:primaryType="nt:unstructured"
handler="function(){CQ_collab_forum_openCollabAdmin();}"
text="Manage comments"/>
</cq:actionConfigs>
</jcr:root>
Vedi Aggiungere una nuova azione a una barra degli strumenti di un componente come esempio per l’interfaccia touch.
La cq:formParameters
nodo (tipo nodo) nt:unstructured
) definisce parametri aggiuntivi aggiunti al modulo di dialogo. Ogni proprietà viene mappata su un parametro di modulo.
La seguente configurazione aggiunge un parametro chiamato name
, impostato con il valore photos/primary
al modulo di dialogo:
<cq:formParameters
jcr:primaryType="nt:unstructured"
name="photos/primary"/>
La cq:inplaceEditing
nodo (tipo nodo) cq:InplaceEditingConfig
) definisce una configurazione di modifica locale per il componente. Può avere le seguenti proprietà:
Nome proprietà | Valore proprietà |
active |
(boolean ) True per abilitare la modifica locale del componente. |
configPath |
(String ) Percorso della configurazione dell'editor. La configurazione può essere specificata da un nodo di configurazione. |
editorType |
(
|
La seguente configurazione abilita la modifica locale del componente e definisce plaintext
come tipo di editor:
<cq:inplaceEditing
jcr:primaryType="cq:InplaceEditingConfig"
active="{Boolean}true"
editorType="plaintext"/>
La cq:listeners
nodo (tipo nodo) cq:EditListenersConfig
) definisce cosa accade prima o dopo un’azione sul componente. Nella tabella seguente sono definite le proprietà possibili.
Nome proprietà | Valore proprietà |
Valore predefinito (Solo interfaccia classica) |
beforedelete |
Il gestore viene attivato prima della rimozione del componente. |
|
beforeedit |
Il gestore viene attivato prima della modifica del componente. | |
beforecopy |
Il gestore viene attivato prima della copia del componente. | |
beforemove |
Il gestore viene attivato prima dello spostamento del componente. | |
beforeinsert |
Il gestore viene attivato prima dell’inserimento del componente. Operativo solo per l’interfaccia touch. |
|
beforechildinsert |
Il gestore viene attivato prima che il componente venga inserito all’interno di un altro componente (solo contenitori). | |
afterdelete |
Il gestore viene attivato dopo la rimozione del componente. | REFRESH_SELF |
afteredit |
Il gestore viene attivato dopo la modifica del componente. | REFRESH_SELF |
aftercopy |
Il gestore viene attivato dopo la copia del componente. | REFRESH_SELF |
afterinsert |
Il gestore viene attivato dopo l’inserimento del componente. | REFRESH_INSERTED |
aftermove |
Il gestore viene attivato dopo lo spostamento del componente. | REFRESH_SELFMOVED |
afterchildinsert |
Il gestore viene attivato dopo che il componente è stato inserito all’interno di un altro componente (solo contenitori). |
La REFRESH_INSERTED
e REFRESH_SELFMOVED
I gestori sono disponibili solo nell’interfaccia classica.
I valori predefiniti per i listener sono impostati solo nell'interfaccia classica.
Nel caso di componenti nidificati, ci sono alcune restrizioni alle azioni definite come proprietà nel cq:listeners
nodo:
Per i componenti nidificati, i valori delle seguenti proprietà deve essere REFRESH_PAGE
:
aftermove
aftercopy
Il gestore eventi può essere implementato con un'implementazione personalizzata. Ad esempio, dove project.customerAction
è un metodo statico):
afteredit = "project.customerAction"
L’esempio seguente è equivalente al REFRESH_INSERTED
configurazione:
afterinsert="function(path, definition) { this.refreshCreated(path, definition); }"
Per informazioni sull’interfaccia classica, per vedere quali parametri possono essere utilizzati nei gestori, consulta before<action>
e after<action>
sezione eventi CQ.wcm.EditBar
e CQ.wcm.EditRollover
documentazione del widget.
Con la seguente configurazione, la pagina viene aggiornata dopo che il componente è stato eliminato, modificato, inserito o spostato:
<cq:listeners
jcr:primaryType="cq:EditListenersConfig"
afterdelete="REFRESH_PAGE"
afteredit="REFRESH_PAGE"
afterinsert="REFRESH_PAGE"
afterMove="REFRESH_PAGE"/>