Architecture de contenu

Suivez le modèle de David

David's Model a été écrit par David Nuescheler il y a des années, mais les idées sont vraies aujourd'hui. Les principaux principes du modèle de David sont les suivants :

D’abord les données, ensuite la structure. OK.
Dirigez la hiérarchie du contenu, ne laissez pas cela se produire.
Les espaces de travail sont destinés à clone(), merge() et update().
Attention aux frères et soeurs du même nom.
Les références sont considérées comme dangereuses.
Les fichiers sont des fichiers.
Les identifiants, c’est le mal.

David's Model se trouve sur le wiki Jackrabbit à l'adresse : https://wiki.apache.org/jackrabbit/DavidsModel.

Tout est contenu

Tout doit être stocké dans le référentiel plutôt que de s’appuyer sur des sources de données tierces distinctes, telles que des bases de données. Cela s’applique au contenu créé, aux données binaires telles que les images, le code et les configurations. Cela nous permet d’utiliser un seul ensemble d’API pour gérer tout le contenu et gérer la promotion de ce contenu par le biais de la réplication. Vous obtenez également une source unique de sauvegarde, de journalisation, etc.

Utiliser le principe de conception "d’abord le modèle de contenu"

Lors de la mise au point d’une fonctionnalité, commencez toujours par concevoir la structure du contenu JCR, puis tâchez de lire et d’écrire votre contenu à l’aide des servlets Sling par défaut. Cela vous permet de vous assurer que votre mise en oeuvre fonctionne bien avec les mécanismes de contrôle d’accès prêts à l’emploi et d’éviter de générer des servlets inutiles de type CRUD.

Soyez RESTful

Les servlets doivent être définis en fonction des types de ressource plutôt que des chemins d’accès. Ainsi, il est possible d’utiliser les contrôles d’accès JCR, de respecter les principes REST, ainsi que d’utiliser la ressource et le résolveur de ressources qui sont mis à notre disposition dans la requête. Cela nous permet également de modifier les scripts qui effectuent le rendu des URL du côté serveur, sans devoir modifier une quelconque URL du côté client et sans révéler au client les détails d’implémentation côté serveur, d’où une sécurité accrue.

Évitez de définir de nouveaux types de nœud

Les types de nœud fonctionnent à un niveau inférieur du calque d’infrastructure. Il est, en outre, possible de répondre à la plupart des exigences en utilisant une propriété sling:resourceType affectée à un type de nœud nt:unstructured, oak:Unstructured, sling:Folder ou cq:Page. Les types de noeuds correspondent au schéma dans le référentiel et la modification des types de noeuds peut s’avérer coûteuse à long terme.

Respectez les conventions de nommage dans le JCR

Le respect des conventions d’appellation ajoute de la cohérence à votre base de code, ce qui réduit le taux d’incidence des défauts et accroît la vitesse des développeurs travaillant dans le système. Adobe respecte les conventions suivantes dans le cadre du développement d’AEM :

Noms des noeuds
- Toutes les minuscules
- Séparation des mots à l’aide de tirets
Noms de propriété
- casse Camel, commençant par une lettre minuscule
Composants (JSP/HTML)
- Toutes les minuscules
- Séparation des mots à l’aide de tirets