Show Menu
TOPICS×

Personalizzazione dei componenti core

I componenti Sviluppo di componenti core core implementano diversi pattern che consentono una facile personalizzazione, dallo stile semplice al riutilizzo avanzato delle funzionalità.

Architettura flessibile

I componenti core sono stati progettati fin dall'inizio per essere flessibili ed estensibili. Una panoramica della loro architettura mostra dove è possibile eseguire la personalizzazione.
E tutti i componenti core implementano Style System .

AEM Project Archetype

AEM Project Archetype crea un progetto Adobe Experience Manager minimo come punto di partenza per i tuoi progetti, incluso un esempio di componente HTL personalizzato con SlingModels per la logica e la corretta implementazione dei componenti core con il pattern proxy consigliato.

Pattern di personalizzazione

Personalizzazione delle finestre di dialogo

È possibile personalizzare le opzioni di configurazione disponibili nella finestra di dialogo di un componente di base, sia che si tratti della finestra di dialogo Progettazione che della finestra di dialogo Modifica.
Ogni finestra di dialogo ha una struttura di nodi coerente. È consigliabile che questa struttura venga replicata in un componente ereditario in modo che Sling Resource Merger e Nascondi condizioni possano essere utilizzate per nascondere, sostituire o riordinare le sezioni della finestra di dialogo originale. La struttura da replicare è definita come qualsiasi cosa fino al livello del nodo dell'elemento tabulazione.
Per essere pienamente compatibile con qualsiasi modifica apportata a una finestra di dialogo sulla versione corrente, è molto importante che le strutture al di sotto del livello dell'elemento tabulazione non vengano toccate (nascoste, aggiunte, sostituite, riordinate, ecc.). Al contrario, un elemento scheda dell'elemento padre deve essere nascosto tramite la
sling:hideResource
proprietà (vedere Proprietà sling-resource-merger.html fusione risorsa Sling), e nuovi elementi scheda aggiunti che contengono i campi di configurazione personalizzati.
sling:orderBefore
può essere utilizzato per riordinare gli elementi tabulazione, se necessario.
La finestra di dialogo seguente illustra la struttura di dialogo consigliata e come nascondere e sostituire una scheda ereditata come descritto in precedenza:
<?xml version="1.0" encoding="UTF-8"?> <jcr:root xmlns:sling="https://sling.apache.org/jcr/sling/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0" xmlns:granite="https://www.adobe.com/jcr/granite/1.0" jcr:primaryType="nt:unstructured"> <content jcr:primaryType="nt:unstructured"> <items jcr:primaryType="nt:unstructured"> <tabs jcr:primaryType="nt:unstructured"> <items jcr:primaryType="nt:unstructured"> <originalTab jcr:primaryType="nt:unstructured" sling:hideResource="true"/> </originalTab> <myTab jcr:primaryType="nt:unstructured" jcr:title="My Tab" sling:resourceType="granite/ui/components/coral/foundation/container"/> <!-- myTab content --> </myTab> </items> </basic> </items> </content> </jcr:root>

Personalizzazione della logica di un componente core

La business logic per i componenti core è implementata in Sling Models. Questa logica può essere estesa utilizzando un pattern di delega Sling.
Ad esempio, il componente core del titolo utilizza la
jcr:title
proprietà della risorsa richiesta per fornire il testo del titolo. Se non viene definita alcuna
jcr:title
proprietà, viene implementato un fallback al titolo della pagina corrente. Modificare il comportamento in modo che il titolo della pagina corrente sia sempre visualizzato.
Poiché l'implementazione dei modelli dei componenti core è privata, è necessario estenderli con un pattern di delega.
@Model(adaptables = SlingHttpServletRequest.class, adapters = Title.class, resourceType = "myproject/components/pageHeadline") public class PageHeadline implements Title { @ScriptVariable private Page currentPage; @Self @Via(type = ResourceSuperType.class) private Title title; @Override public String getText() { return currentPage.getTitle(); } @Override public String getType() { return title.getType(); } }
Per ulteriori dettagli sul modello di delega vedere i componenti core GitHub Wiki articolo Modello di delega per i modelli Sling.

Personalizzazione del codice

A volte lo stile avanzato richiede una diversa struttura di marcatura del componente.
Questo può essere fatto facilmente copiando i file HTL che devono essere modificati dal componente core al componente proxy.
Riprendendo l’esempio del componente Breadcrumb di base, per personalizzare l’output del codice, il
breadcrumb.html
file deve essere copiato nel componente specifico del sito con un componente
sling:resourceSuperTypes
che punta al componente Breadcrumb di base.

Attribuzione dello stile ai componenti

La prima forma di personalizzazione consiste nell'applicare stili CSS.
Per semplificare questa procedura, i componenti core eseguono il rendering dei commenti semantici e seguono una convenzione di denominazione standard ispirata a Bootstrap . Inoltre, per definire facilmente gli stili dei singoli componenti, ogni componente core è racchiuso in un elemento DIV con le classi "
cmp
" e "
cmp-<name>
".
Ad esempio, guardando il file HTL del componente Breadcrumb v1 core: breadcrumb.html , vediamo che la gerarchia degli elementi di output è
ol.breadcrumb > li.breadcrumb-item > a
. Per essere certi che una regola CSS influisca solo sulla classe di breadcrumb del componente, tutte le regole devono essere spaccate con il nome, come illustrato di seguito:
.cmp-breadcrumb .breadcrumb {} .cmp-breadcrumb .breadcrumb-item {} .cmp-breadcrumb a {}
Inoltre, ciascuno dei componenti core utilizza la funzione AEM Style System che consente agli autori dei modelli di definire nomi di classe CSS aggiuntivi che possono essere applicati al componente dagli autori delle pagine. Questo consente di definire per ciascun modello un elenco degli stili di componente consentiti e se uno di essi deve essere applicato per impostazione predefinita a tutti i componenti di tale tipo.

Compatibilità degli aggiornamenti delle personalizzazioni

Sono possibili tre diversi tipi di upgrade:
  • aggiornamento della versione di AEM
  • aggiornamento dei componenti core a una nuova versione secondaria
  • aggiornamento dei componenti core a una versione principale
In genere, l'aggiornamento di AEM a una nuova versione non influisce sui componenti core o sulle personalizzazioni eseguite, a condizione che le versioni dei componenti supportino anche la nuova versione di AEM a cui viene eseguita la migrazione e che le personalizzazioni non utilizzino API che sono state eliminate o rimosse .
L'aggiornamento dei componenti core senza passare a una versione principale più recente non dovrebbe influenzare le personalizzazioni, purché siano utilizzati i pattern di personalizzazione descritti in questa pagina.
Il passaggio a una nuova versione principale dei componenti core è compatibile solo per la struttura del contenuto, ma potrebbe essere necessario reimpostare le personalizzazioni. Per ogni versione di componente verranno pubblicati registri di modifiche chiare per evidenziare le modifiche che influirebbero sul tipo di personalizzazioni descritto in questa pagina.

Supporto delle personalizzazioni

Come per qualsiasi componente di AEM, è necessario essere consapevoli di una serie di aspetti relativi alle personalizzazioni:
  1. Non modificare mai direttamente il codice dei componenti core.
    In questo modo non saranno completamente supportati e i futuri aggiornamenti dei componenti risulteranno dolorosi. Utilizzate invece i metodi di personalizzazione descritti in questa pagina.
  2. Il codice personalizzato è una vostra responsabilità.
    Il nostro programma di supporto non copre il codice personalizzato, e i problemi segnalati che non possono essere riprodotti con i componenti core della vaniglia utilizzati come documentati non saranno considerati idonei.
  3. Funzionalità obsolete e rimosse.
    Con l’aggiornamento di ciascuna nuova versione di AEM, accertati che tutte le API utilizzate siano ancora di attualità, controllando attentamente la pagina Funzioni deprecated-removed-features.html obsolete e rimosse.
Vedere anche la sezione Supporto dei componenti core.
Articolo successivo:
  • Utilizzo dei componenti di base: per iniziare a usare i componenti di base nel tuo progetto.
  • Linee guida per i componenti - per apprendere i pattern di implementazione dei componenti core.