Show Menu
ARGOMENTI×

Architettura dei contenuti

Segui il modello di David

Il Modello di David è stato scritto da David Nuescheler anni fa, ma le idee sono vere oggi. I principali principi del modello di David sono i seguenti:
  • I dati vengono prima, la struttura dopo. Forse.
  • Guidare la gerarchia dei contenuti, non lasciarla accadere.
  • Le aree di lavoro sono per clone() , merge() e update() .
  • Fai attenzione ai fratelli dello stesso nome.
  • I riferimenti sono considerati dannosi.
  • I file sono file.
  • Gli ID sono malvagi.
Il modello di David è disponibile sul wiki Jackrabbit all’indirizzo https://wiki.apache.org/jackrabbit/DavidsModel .

Tutto è contenuto

Tutto deve essere memorizzato nell'archivio anziché basarsi su origini dati di terze parti separate, come i database. Questo vale per i contenuti creati, dati binari come immagini, codice, configurazioni, ecc. Questo consente di utilizzare un set di API per gestire tutto il contenuto e per gestire la promozione di tale contenuto tramite la replica. Abbiamo anche un'unica fonte di backup, registrazione, ecc.

Utilizzare il principio di progettazione "content model first"

Quando create una nuova funzione, iniziate sempre progettando la struttura del contenuto JCR, quindi cercate di leggere e scrivere il contenuto utilizzando i servlet Sling predefiniti. Questo vi consentirà di garantire il buon funzionamento dell'implementazione con meccanismi di controllo dell'accesso out-of-box e di evitare la generazione di servlet CRUD non necessari.

Sii RESTful

I servlet devono essere definiti in base a resourceTypes anziché ai percorsi. Questo consente di utilizzare i controlli di accesso JCR, aderire ai principi REST e utilizzare il risolutore di risorse e risorse fornito nella richiesta. Questo consente anche di modificare gli script che eseguono il rendering degli URL sul lato server senza dover modificare alcun URL dal lato client, nascondendo al contempo dal client i dettagli di implementazione lato server per una maggiore sicurezza.

Evitare di definire nuovi tipi di nodo

I tipi di nodo funzionano a un livello basso nel livello dell'infrastruttura e la maggior parte dei requisiti può essere soddisfatta utilizzando un tipo di nodo sling:resourceType assegnato a un tipo di nodo nt:unstructure, oak:Unstructure, sling:Folder o cq:Page. I tipi di nodo equivalgono allo schema nel repository e la modifica dei tipi di nodo può essere molto costoso lungo la strada.

Conformità alle convenzioni di denominazione nel JCR

Il rispetto delle convenzioni di denominazione darà coerenza alla base di codice, riducendo il tasso di incidenza dei difetti e aumentando la velocità degli sviluppatori che lavorano nel sistema. Nello sviluppo di AEM, Adobe utilizza le seguenti convenzioni:
  • Nomi nodo
    • Tutte le maiuscole
    • Separazione delle parole mediante trattini
  • Nomi proprietà
    • Cassa del cammello, a partire da una lettera minuscola
  • Componenti (JSP/HTML)
    • Tutte le maiuscole
    • Separazione delle parole mediante trattini