Sviluppo AEM - Linee guida e best practice aem-development-guidelines-and-best-practices
Linee guida per l’utilizzo di modelli e componenti guidelines-for-using-templates-and-components
I componenti e i modelli di Adobe Experience Manager (AEM) comprendono un potente toolkit. Possono essere utilizzati dagli sviluppatori per fornire agli utenti aziendali dei siti web, agli editor e agli amministratori la funzionalità di adattare i loro siti web alle mutevoli esigenze aziendali (agilità dei contenuti). Tutto questo mantenendo l'uniformità del layout dei siti (protezione del marchio).
Una sfida tipica per una persona responsabile di un sito Web o di un insieme di siti Web (ad esempio, in una filiale di un'azienda globale) consiste nell'introdurre un nuovo tipo di presentazione dei contenuti sui propri siti Web.
Supponiamo che sia necessario aggiungere ai siti web una pagina di elenco delle novità, in cui sono elencati estratti da altri articoli già pubblicati. La pagina deve avere la stessa progettazione e struttura del resto del sito web.
Il modo consigliato per affrontare tale sfida consiste nel:
- Riutilizzare un modello esistente per creare un tipo di pagina. Il modello definisce approssimativamente la struttura della pagina (elementi di navigazione, pannelli e così via), che viene ulteriormente perfezionata dal relativo design (CSS, grafica).
- Utilizza il sistema paragrafo (parsys/iparsys) nelle nuove pagine.
- Definire il diritto di accesso alla modalità Progettazione dei sistemi paragrafo, in modo che solo le persone autorizzate (in genere l’amministratore) possano modificarli.
- Definisci i componenti consentiti nel sistema paragrafo specificato in modo che gli editor possano quindi inserire i componenti richiesti nella pagina. In questo caso, potrebbe essere un componente elenco, che può attraversare una sottostruttura di pagine ed estrarre le informazioni in base a regole predefinite.
- Gli editor aggiungono e configurano i componenti consentiti sulle pagine di cui sono responsabili, per fornire all’azienda le funzionalità (informazioni) richieste.
Questo illustra come questo approccio consenta agli utenti e agli amministratori del sito web che vi contribuiscono di rispondere rapidamente alle esigenze aziendali senza richiedere il coinvolgimento di team di sviluppo. I metodi alternativi, come la creazione di un modello, sono in genere costosi e richiedono un processo di gestione delle modifiche e il coinvolgimento del team di sviluppo. Ciò rende l'intero processo più lungo e costoso.
Gli sviluppatori di sistemi basati sull’AEM dovrebbero pertanto utilizzare:
- modelli e controllo di accesso alla progettazione del sistema paragrafo per uniformità e protezione del brand
- sistema paragrafo, incluse le opzioni di configurazione per la flessibilità.
Le seguenti regole generali per gli sviluppatori hanno senso nella maggior parte dei progetti comuni:
- Mantieni basso il numero di modelli, anche se si tratta solo del numero di strutture di pagina fondamentalmente diverse sui siti web.
- Fornisci la flessibilità e le funzionalità di configurazione necessarie ai componenti personalizzati.
- Massimizzare l'uso della potenza e della flessibilità del sistema paragrafo dell'AEM - i componenti parsys e iparsys.
Personalizzazione di componenti e altri elementi customizing-components-and-other-elements
Quando crei componenti personalizzati o personalizzi un componente esistente, spesso è più semplice (e sicuro) riutilizzare le definizioni esistenti. Gli stessi principi si applicano anche ad altri elementi all’interno dell’AEM, ad esempio il gestore degli errori.
Questo può essere fatto copiando e sovrapponendo la definizione esistente. In altre parole, copiare la definizione da /libs a /apps/<your-project>. Questa nuova definizione, in /apps, può essere aggiornato in base alle tue esigenze.
Ad esempio:
-
Personalizzazione di un componente
Ciò comportava la sovrapposizione di una definizione di componente:
-
Creare una cartella di componenti in
/apps/<website-name>/components/<MyComponent>copiando un componente esistente:-
Ad esempio, per personalizzare la copia del componente Testo:
- da
/libs/foundation/components/text - a
/apps/myProject/components/text
- da
-
-
-
Personalizzazione delle pagine visualizzate dal gestore degli errori
Questo caso prevede la sovrapposizione di un servlet:
-
Nell’archivio, copia uno o più script predefiniti:
- da
/libs/sling/servlet/errorhandler/ - a
/apps/sling/servlet/errorhandler/
- da
-
/libs percorso./libs viene sovrascritto al successivo aggiornamento dell’istanza (e potrebbe benissimo essere sovrascritto quando applichi un hotfix o un feature pack).- copia elemento in
/libsa/apps - apporta le modifiche in
/apps
Quando utilizzare le query JCR e quando non utilizzarle when-to-use-jcr-queries-and-when-not-to-use-them
Le query JCR sono uno strumento potente se utilizzato correttamente. Essi sono appropriati per:
-
query reali degli utenti finali, ad esempio ricerche full-text sul contenuto.
-
occasioni in cui i contenuti strutturati devono essere trovati nell’intero archivio.
In questi casi, assicurati che le query vengano eseguite solo quando necessario. Ad esempio, all’attivazione di un componente o all’annullamento della validità della cache (anziché, ad esempio, Passaggi dei flussi di lavoro, Gestori di eventi che si attivano in caso di modifiche del contenuto e Filtri).
Non utilizzare mai query JCR per richieste di rendering puro. Ad esempio, le query JCR non sono appropriate per i seguenti elementi:
- navigazione rendering
- creazione di una panoramica sulle "prime 10 ultime notizie"
- visualizzazione dei conteggi degli elementi di contenuto
Per il rendering del contenuto, utilizza l’accesso di navigazione alla struttura del contenuto anziché eseguire una query JCR.
Considerazioni sulla sicurezza security-considerations
Sessioni JCR (archivio) jcr-repository-sessions
Utilizza la sessione utente, non la sessione amministrativa. Ciò significa che deve utilizzare:
slingRequest.getResourceResolver().adaptTo(Session.class);
Protect contro il cross-site scripting (XSS) protect-against-cross-site-scripting-xss
Il cross-site scripting (XSS) consente agli aggressori di inserire codice nelle pagine web visualizzate da altri utenti. Questa vulnerabilità di sicurezza può essere sfruttata da utenti Web malintenzionati per aggirare i controlli di accesso.
L'AEM applica il principio di filtrare tutti i contenuti forniti dall'utente al momento dell'output. Prevenire l’XSS è data la massima priorità sia durante lo sviluppo che durante il test.
Inoltre, un firewall per le applicazioni web, ad esempio mod_security per Apache, è in grado di fornire un controllo centrale e affidabile sulla sicurezza dell'ambiente di distribuzione e di proteggere da attacchi di cross-site scripting non rilevati in precedenza.
La scheda di riferimento rapido API XSS contiene informazioni necessarie per utilizzare l’API XSS e rendere più sicura un’app AEM. Puoi scaricarlo qui:
Scheda di riferimento rapido XSSAPI.
Come proteggere la comunicazione per informazioni confidenziali securing-communication-for-confidential-information
Come per qualsiasi applicazione su Internet, accertati che quando trasporti informazioni riservate
- il traffico è protetto tramite SSL
- Se applicabile, viene utilizzato HTTP POST
Questo vale per le informazioni riservate al sistema (come la configurazione o l'accesso amministrativo) e per le informazioni riservate ai suoi utenti (come i dati personali)
Attività di sviluppo distinte distinct-development-tasks
Personalizzazione delle pagine di errore customizing-error-pages
Le pagine di errore possono essere personalizzate per l’AEM. È consigliabile evitare che l’istanza riveli tracce sling in caso di errori interni del server.
Consulta Personalizzazione delle pagine di errore visualizzate dal gestore degli errori per informazioni dettagliate.
Apri file nel processo Java™ open-files-in-the-java-process
Poiché l’AEM può accedere a molti file, si consiglia di specificare il numero aprire file per un processo Java™ essere configurato in modo esplicito per l’AEM.
Per ridurre al minimo questo problema, lo sviluppo deve garantire che qualsiasi file aperto venga chiuso correttamente quando (significativamente) possibile.