Inhaltsarchitektur content-architecture

CAUTION
AEM 6.4 hat das Ende der erweiterten Unterstützung erreicht und diese Dokumentation wird nicht mehr aktualisiert. Weitere Informationen finden Sie in unserer technische Unterstützung. Unterstützte Versionen suchen here.

David's Modell folgen follow-david-s-model

„David’s Model“ wurde vor Jahren von David Nuescheler entworfen, hat aber bis heute Gültigkeit. Die wichtigsten Grundsätze des Modells lauten:

  • Erst die Daten, dann die Struktur. Zumindest gegebenenfalls.
  • Steuern Sie die Content-Hierarchie, anstatt sie dem Zufall zu überlassen.
  • Workspaces sind für clone(), merge() und update() vorgesehen.
  • Vorsicht vor gleichnamigen Geschwistern.
  • Verweise gelten als schädlich.
  • Dateien sind Dateien.
  • IDs sind zu vermeiden.

„David’s Model“ finden Sie im Jackrabbit-Wiki unter https://wiki.apache.org/jackrabbit/DavidsModel.

Alles ist Inhalt everything-is-content

Alles sollte im Repository gespeichert werden, anstatt sich auf separate Datenquellen von Drittanbietern wie Datenbanken zu verlassen. Dies gilt für erstellte Inhalte, Binärdaten wie Bilder, Code, Konfigurationen usw. Auf diese Weise können wir eine Reihe von APIs verwenden, um alle Inhalte zu verwalten und die Promotion dieses Inhalts durch Replikation zu verwalten. Wir erhalten auch eine einzige Quelle für Backup, Protokollierung usw.

Verwenden des Designprinzips "Inhaltsmodell zuerst" use-the-content-model-first-design-principle

Wenn Sie eine neue Funktion entwickeln, beginnen Sie immer damit, zunächst die JCR-Inhaltsstruktur zu entwerfen. Befassen Sie sich dann erst mit dem Lesen und Schreiben Ihrer Inhalte mithilfe der standardmäßigen Sling-Servlets. Auf diese Weise können Sie sicherstellen, dass Ihre Implementierung problemlos mit Standardmechanismen für die Zugriffssteuerung funktioniert, und darüber hinaus die Erstellung überflüssiger Servlets im CRUD-Stil vermeiden.

RESTful statt Panik be-restful

Servlets sollten auf Basis von Ressourcentypen anstelle von Pfaden definiert werden. Dies ermöglicht die Verwendung von JCR-Zugriffssteuerungen, die Anwendung der REST-Prinzipien und die Verwendung der Ressource und des Ressourcen-Resolvers, die in der Anforderung bereitgestellt werden. Damit lassen sich außerdem die Skripte ändern, die URLs auf Serverseite rendern, ohne die URLs auf Client-Seite ändern zu müssen, während die serverseitigen Implementierungsdetails vor dem Client verborgen werden, um die Sicherheit zu erhöhen.

Vermeiden der Definition neuer Knotentypen avoid-defining-new-node-types

Knotentypen setzen auf einer niedrigen Ebene der Infrastrukturschicht an und die meisten Anforderungen können erfüllt werden, indem ein „sling:resourceType“ verwendet wird, der einem Knotentyp „nt:unstructured“, „oak:Unstructured“, „sling:Folder“ oder „cq:Page“ zugewiesen ist. Knotentypen entsprechen dem Schema im Repository und das Ändern von Knotentypen kann sich äußerst aufwendig gestalten.

Einhalten Sie Namenskonventionen im JCR adhere-to-naming-conventions-in-the-jcr

Durch die Einhaltung von Namenskonventionen wird die Konsistenz der Codebasis erhöht, die Fehler-Inzidenzrate gesenkt und der Arbeitsprozess der beteiligten Entwickler beschleunigt. Adobe wendet die folgenden Konventionen bei der Entwicklung von AEM an:

  • Knotennamen

    • Kleinbuchstaben
    • Worttrennung mithilfe von Bindestrichen
  • Eigenschaftsnamen

    • Groß-/Kleinschreibung, beginnend mit einem Kleinbuchstaben
  • Komponenten (JSP/HTML)

    • Kleinbuchstaben
    • Worttrennung mithilfe von Bindestrichen
recommendation-more-help
2315f3f5-cb4a-4530-9999-30c8319c520e