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.
L'inclusione degli script in JSP rende difficile il debug dei problemi nel codice. Inoltre, includendo gli script in JSP, è difficile separare la logica di business dal livello di visualizzazione, che è una violazione del principio di responsabilità singola e del modello di progettazione MVC.
Il codice viene scritto una volta, ma letto molte volte. Trascorrere un po' di tempo in anticipo per pulire il codice che scriviamo pagherà dividendi lungo la strada come noi e altri sviluppatori hanno bisogno di leggerlo più tardi.
Idealmente, un altro programmatore non dovrebbe dover aprire un modulo per capire cosa fa. Allo stesso modo, dovrebbero essere in grado di dire cosa fa un metodo senza leggerlo. Meglio possiamo abbonarci a queste idee, più facile sarà leggere il nostro codice e più velocemente saremo in grado di scrivere e cambiare il nostro codice.
Nella base di codice AEM vengono utilizzate le seguenti convenzioni:
<Interface>Impl
, vale a dire ReaderImpl
.<Variant><Interface>
, vale a dire JcrReader
e FileSystemReader
.Abstract<Interface>
o Abstract<Variant><Interface>
.com.adobe.product.module
. Ogni artefatto Maven o bundle OSGi deve avere un proprio pacchetto.Tieni presente che queste convenzioni non devono necessariamente essere applicate alle implementazioni dei clienti, ma è importante che le convenzioni siano definite e rispettate in modo che il codice possa rimanere gestibile.
Idealmente, i nomi dovrebbero rivelare le loro intenzioni. Un test comune del codice per quando i nomi non sono chiari come dovrebbero essere è la presenza di commenti che spiegano a cosa serve la variabile o il metodo:
Non chiaro |
Cancella |
int d; //tempo trascorso in giorni |
int elapsedTimeInDays; |
//Ottenere immagini con tag |
public List getTaggedImages() {} |
DRY afferma che lo stesso set di codice non deve mai essere duplicato. Questo vale anche per cose come le stringhe letterali. La duplicazione del codice apre la strada ai difetti ogni volta che qualcosa deve cambiare e deve essere ricercato ed eliminato.
Le regole CSS devono essere specifiche per l’elemento di destinazione nel contesto dell’applicazione. Ad esempio, una regola CSS applicata a .content .center sarebbe eccessivamente ampio e potrebbe potenzialmente influenzare molti contenuti nel sistema, richiedendo ad altri di ignorare questo stile in futuro. .myapp-centertext sarebbe una regola più specifica mentre specifica centrato text nel contesto dell'applicazione.
Quando un’API è obsoleta, è sempre meglio trovare il nuovo approccio consigliato invece di basarsi sull’API obsoleta. In questo modo gli aggiornamenti saranno più semplici in futuro.
Le stringhe che non vengono fornite da un autore devono essere racchiuse in una chiamata al dizionario i18n di AEM tramite I18n.get() in JSP/Java e CQ.I18n.get() in JavaScript. Questa implementazione restituirà la stringa che gli è stata passata se non viene trovata alcuna implementazione, quindi offre la flessibilità di implementare la localizzazione dopo l'implementazione delle funzionalità nella lingua primaria.
Anche se i percorsi nel JCR non devono contenere spazi, la loro presenza non deve causare l'interruzione del codice. Jackrabbit fornisce una classe di utilità di testo con escape() e escapePath() metodi. Per i JSP, l’interfaccia Granite espone un granite:encodeURIPath() EL funzione .
AEM fornisce un’API XSS per pulire facilmente i parametri e garantire la sicurezza dagli attacchi di script tra siti diversi. Inoltre, HTL dispone di queste protezioni integrate direttamente nel linguaggio dei modelli. È disponibile un foglio di supporto API da scaricare all’indirizzo Sviluppo - Linee guida e best practice.
Per il codice Java, AEM supporta slf4j come API standard per la registrazione dei messaggi e deve essere utilizzato insieme alle configurazioni rese disponibili tramite la console OSGi per motivi di coerenza nell’amministrazione. Slf4j espone cinque diversi livelli di registrazione. È consigliabile utilizzare le seguenti linee guida quando si sceglie a quale livello registrare un messaggio:
Nel caso di JavaScript, console.log deve essere utilizzato solo durante lo sviluppo e tutte le istruzioni di registro devono essere rimosse prima del rilascio.
Evita di copiare il codice senza capire cosa fa. In caso di dubbi, è sempre meglio chiedere a qualcuno che ha più esperienza con il modulo o l’API su cui non sei chiaro.