Show Menu
TOPICS×

Linee guida per i componenti

I componenti Sviluppo di componenti core core seguono modelli di implementazione moderni che sono molto diversi dai componenti di base.
In questa pagina sono illustrati questi pattern e quando utilizzarli per creare componenti modificabili personalizzati. La prima sezione Pattern componenti generali si applica a qualsiasi tipo di componente, mentre la seconda sezione Modelli componenti riutilizzabili si applica ai componenti destinati a essere riutilizzati tra siti o progetti, come ad esempio i Componenti principali.

Pattern di componenti generali

Le linee guida di questa sezione sono consigliate per qualsiasi tipo di componente, a prescindere dal fatto che il componente sia specifico per un singolo progetto o che sia destinato a essere ampiamente riutilizzato su più siti o progetti.

Componenti configurabili

I componenti possono avere finestre di dialogo con diverse opzioni. Questo dovrebbe essere sfruttato per rendere i componenti flessibili e configurabili ed evitare di implementare più componenti che sono per lo più varianti l'uno dell'altro.
In genere, se un wireframe o un progetto contiene varianti di elementi simili, queste varianti non devono essere implementate come componenti diversi, ma come un componente con opzioni per scegliere tra le varianti.
Per fare un passo avanti, se i componenti vengono riutilizzati tra siti o progetti, consulta la sezione Capacità preconfigurabili.

Separazione delle preoccupazioni

In genere è consigliabile tenere separata la logica (o il modello) di un componente dal modello (o dalla vista) di marcatura. Esistono diversi modi per ottenere questo risultato, tuttavia quello consigliato è quello di utilizzare i modelli models.html Sling per la logica e il linguaggio HTL ( HTML Template Language) per la marcatura, come fanno anche i componenti core.
Sling Models è una serie di annotazioni Java per accedere facilmente alle variabili necessarie dai POJO, e quindi offre un modo semplice, potente ed efficiente per implementare la logica Java per i componenti.
HTL è stato progettato per essere un linguaggio di modello semplice e sicuro, personalizzato per AEM. Può chiamare molte forme di logica, che la rende molto flessibile.

Pattern di componenti riutilizzabili

Le linee guida di questa sezione possono essere utilizzate anche per qualsiasi tipo di componente, ma hanno più senso per i componenti che devono essere riutilizzati tra siti o progetti, come ad esempio i componenti core. Queste linee guida possono pertanto essere ignorate per i componenti utilizzati solo su un singolo sito o progetto.

Capacità preconfigurabili

Oltre alla finestra di dialogo di modifica utilizzata dagli autori delle pagine, i componenti possono anche avere una finestra di dialogo di progettazione per consentire agli autori dei modelli di preconfigurarli. L'Editor templates.html modelli consente di impostare tutte queste preconfigurazioni, che sono denominate "Criteri".
Per rendere i componenti il più possibile riutilizzabili, è necessario fornire loro opzioni significative per la preconfigurazione. Questo consente di abilitare o disabilitare le funzioni dei componenti per soddisfare le esigenze specifiche dei diversi siti.

Pattern componente proxy

Poiché ogni risorsa di contenuto ha una
sling:resourceType
proprietà che fa riferimento al componente per eseguirne il rendering, in genere è buona norma che queste proprietà facciano riferimento a componenti specifici del sito, invece di puntare a componenti condivisi da più siti. Ciò offre maggiore flessibilità ed evita il refactoring dei contenuti se un sito necessita di un comportamento diverso per un componente, perché questa personalizzazione può essere ottenuta sul componente specifico del sito e non interesserà gli altri siti.
Tuttavia, affinché i componenti specifici del progetto non duplichino codice, devono fare riferimento ciascuno al componente principale condiviso con la
sling:resourceSuperType
proprietà. Questi componenti specifici del progetto che si riferiscono solo ai componenti padre sono denominati "componenti proxy". I componenti proxy possono essere completamente vuoti se ereditano completamente la funzionalità o se possono ridefinire alcuni aspetti del componente.

Versione componente

I componenti dovrebbero essere mantenuti completamente compatibili nel tempo, ma a volte sono necessarie modifiche che non possono essere mantenute compatibili. Una soluzione a queste esigenze opposte è introdurre il controllo delle versioni dei componenti aggiungendo un numero nel percorso del tipo di risorsa e nei nomi completi delle classi Java delle rispettive implementazioni. Questo numero di versione rappresenta una versione principale come definita dalle linee guida per il controllo delle versioni semantiche, che viene incrementata solo per le modifiche non compatibili con le versioni precedenti.
Le modifiche non compatibili ai seguenti aspetti dei componenti ne causeranno una nuova versione:
  • Modelli Sling (seguendo le linee guida relative alle versioni semantiche)
  • Script e modelli HTL
  • Selettori HTML e CSS
  • Rappresentazione JSON
  • Finestre di dialogo
Per ulteriori dettagli, consulta il documento Criteri di controllo delle versioni in GitHub.
Il controllo delle versioni dei componenti crea una forma di contratto che è importante per gli aggiornamenti, in quanto chiarisce quando potrebbe essere necessario reimpostare qualcosa. Vedi anche la sezione Compatibilità di aggiornamento delle personalizzazioni , che spiega quali considerazioni richiedono diverse forme di personalizzazione per un aggiornamento.
Per evitare migrazioni di contenuti dolorose, è importante non puntare mai direttamente ai componenti con versione dalle risorse di contenuto. Di regola,
sling:resourceType
il contenuto non deve mai avere un numero di versione al suo interno; in caso contrario, l’aggiornamento dei componenti richiederà anche il refactoring del contenuto. Il modo migliore per evitarlo è seguire il pattern del componente proxy descritto in precedenza.

Interfacce modello

Questo pattern riguarda l'
data-sly-use
istruzione HTL di puntare a un'interfaccia Java, mentre l'implementazione del modello Sling si sta registrando anche al tipo di risorsa del componente.
Se combinato con il modello del componente proxy descritto sopra, questo tipo di binding doppia offre i seguenti punti di estensione:
  1. Un sito può ridefinire l'implementazione di un modello Sling registrandolo nel tipo di risorsa del componente proxy, senza doversi preoccupare del file HTL, che può comunque puntare all'interfaccia.
  2. Un sito può ridefinire la marcatura HTL di un componente, senza considerare a quale logica di implementazione deve puntare.

Mettere tutto insieme

Di seguito è riportata una panoramica dell’intera struttura di binding dei tipi di risorsa, ad esempio il componente Titolo principale. Illustra come un componente proxy specifico per il sito possa risolvere il controllo delle versioni dei componenti, per evitare che la risorsa di contenuto contenga un numero di versione qualsiasi. Viene quindi mostrato come il file
title.html
HTL del componente utilizza l’interfaccia del modello, mentre l’implementazione si collega alla versione specifica del componente tramite le annotazioni Modello models.html Sling.
Di seguito è riportata un'altra panoramica, che non mostra i dettagli dell'implementazione del POJO, ma mostra come vengono utilizzati i modelli e i criteri associati.
La
cq:allowedTemplates
proprietà indica quali modelli possono essere utilizzati per un sito e
cq:template
indica per ciascuna pagina quale sia il modello associato. Ogni modello è costituito da tre parti:
  • struttura
    - Contiene le risorse che verranno forzate a essere presenti su ciascuna pagina e che l'autore della pagina non potrà eliminare, come ad esempio i componenti dell'intestazione e del piè di pagina.
  • initial
    - Contiene il contenuto iniziale che verrà duplicato nella pagina al momento della creazione.
  • criteri
    - Contiene per ciascun componente la mappatura a un criterio, ovvero la preconfigurazione del componente. Questa mappatura consente di riutilizzare i criteri tra i modelli, e quindi di essere gestiti a livello centrale.

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 componenti HTL personalizzati con SlingModels per la logica e la corretta implementazione dei componenti core con il pattern proxy consigliato.
Articolo successivo: