AEM: Best Practices per lo Sviluppo di Componenti
AEM: Best Practices per lo Sviluppo di Componenti
Lo sviluppo di componenti in Adobe Experience Manager richiede attenzione a diversi aspetti: performance, manutenibilità, riusabilità. Questa guida è basata su documentazione ufficiale Adobe e best practices verificate della community.
1. HTL: Evita Pattern Anti-Performance
❌ BAD: Ripetere lo stesso test più volte
<h1 data-sly-test="${component.textEnabled}">${component.title}</h1>
<p data-sly-test="${component.textEnabled}">${component.description}</p>Problema: Il test viene eseguito due volte, impattando le performance.
✅ GOOD: Riutilizza i risultati del test
<h1 data-sly-test.textEnabled="${component.textEnabled}">${component.title}</h1>
<p data-sly-test="${textEnabled}">${component.description}</p>Fonte: Adobe HTL Style Guide - Core Components
2. HTL: Usa <sly> invece di <div> con unwrap
❌ BAD: Usare div + unwrap
<div data-sly-include="content.html" data-sly-unwrap></div>
<div data-sly-resource="${item @ selectors='event'}" data-sly-unwrap></div>Problema: Markup inutile e meno leggibile.
✅ GOOD: Usa il tag <sly>
<sly data-sly-include="content.html"></sly>
<sly data-sly-resource="${item @ selectors = 'event'}"></sly>Fonte: Adobe HTL Style Guide
3. HTL: Ordine degli Attributi
❌ BAD: Attributi HTL dopo attributi HTML
<h1 class="cmp-component__title" data-sly-test="${component.title}">
${component.title}
</h1>Problema: Le variabili HTL potrebbero non essere disponibili negli attributi successivi.
✅ GOOD: Attributi HTL prima degli attributi HTML
<h1 data-sly-test="${component.title}" class="cmp-component__title">
${component.title}
</h1>Fonte: Adobe HTL Style Guide
4. HTL: Posiziona data-sly-use al Top-Level
❌ BAD: data-sly-use in elementi annidati
<div class="cmp-teaser">
<h3 data-sly-use.teaser="com.example.models.Teaser">
${teaser.title}
</h3>
<p>${teaser.description}</p>
</div>Problema: Difficile vedere name clashing, rischio di inizializzare oggetti due volte.
✅ GOOD: data-sly-use al livello superiore
<div data-sly-use.teaser="com.example.models.Teaser" class="cmp-teaser">
<h3>${teaser.title}</h3>
<p>${teaser.description}</p>
</div>Fonte: Adobe HTL Style Guide
5. Sling Models: Usa Adobe Recommended Practice
Adobe raccomanda l'uso di Sling Models come best practice per componenti AEM da AEM 6.1+.
@Model(
adaptables = Resource.class,
defaultInjectionStrategy = DefaultInjectionStrategy.OPTIONAL
)
public class TeaserModel {
@ValueMapValue
private String title;
@ValueMapValue
private String description;
public String getTitle() {
return title;
}
public String getDescription() {
return description;
}
}Vantaggi dei Sling Models:
- ✅ Testabilità: Facile scrivere unit test
- ✅ Dependency Injection: Nativa e pulita
- ✅ Riusabilità: Possono essere usati fuori da HTL
- ✅ Manutenibilità: Codice più pulito e leggibile
Fonte: Adobe Experience League - HTL Java Use-API
Quando usare Sling Models vs properties dirette?
- Properties dirette (
${properties.title}): OK per componenti molto semplici senza logica backend - Sling Models: Raccomandati quando serve logica backend, trasformazioni dati, o integrazioni
Fonte: Adobe Experience League Community
6. Separazione tra Business Logic e Presentation
Adobe raccomanda esplicitamente:
"This method allows all complex business logic to be encapsulated in the Java code, while the HTL code deals only with direct markup production."
Cosa va in HTL:
- ✅ Markup HTML
- ✅ Logica di presentazione semplice (condizioni, iterazioni)
- ✅ Interpolazione variabili
Cosa va in Java/Sling Models:
- ✅ Logica di business complessa
- ✅ Calcoli e trasformazioni dati
- ✅ Integrazioni con servizi OSGi
Fonte: Adobe Experience League - HTL Java Use-API
7. Dialog Validation: Sintassi Corretta
❌ SBAGLIATO: validation="email" (non esiste)
<!-- Questa sintassi NON FUNZIONA -->
<email
sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
validation="email"/>✅ CORRETTO: Usa granite:data con regex
<email
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
fieldLabel="Email"
name="./email"
required="{Boolean}true">
<granite:data
jcr:primaryType="nt:unstructured"
validation-regex="^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$"
validation-regex-message="Inserisci un indirizzo email valido"/>
</email>Nota: La sintassi del regex varia tra AEM 6.3 e 6.4+ per l'escaping dei backslash.
Fonti:
8. HTL: Commenti Corretti
❌ BAD: Commenti HTML
<!-- Don't use HTML comments, they appear in final markup -->
<div>${component.title}</div>✅ GOOD: Commenti HTL
<!--/* Use HTL comments, they are removed from output */-->
<div>${component.title}</div>Fonte: Adobe HTL Style Guide
9. HTL: Semplifica Espressioni Ternarie
❌ BAD: Ternario ridondante
<div class="${cssClass ? cssClass : 'my-class'}"></div>✅ GOOD: Usa l'operatore OR
<div class="${cssClass || 'my-class'}"></div>Fonte: Adobe HTL Style Guide
10. HTL: Non Usare Prefissi Getter
❌ BAD: Chiamare getter esplicitamente
<p>${component.getTitle}</p>
<a href="${item.link}" data-sly-unwrap="${item.isActive}">...</a>✅ GOOD: Accedi alle proprietà direttamente
<p>${component.title}</p>
<a href="${item.link}" data-sly-unwrap="${item.active}">...</a>Fonte: Adobe HTL Style Guide
Conclusioni
Queste best practices sono verificate e basate su:
- ✅ Documentazione ufficiale Adobe Experience League
- ✅ HTL Style Guide dei Core Components Adobe
- ✅ Community Adobe Experience League
- ✅ Implementazioni reali nei Core Components
Applicarle ti permetterà di scrivere componenti più manutenibili, performanti e conformi agli standard Adobe.