„David’s Model“ wurde vor Jahren von David Nuescheler entworfen, hat aber bis heute Gültigkeit. Die wichtigsten Grundsätze von David’s Model lauten wie folgt:
clone()
, merge()
und update()
verfügbar.David’s Model kann im Jackrabbit Wiki unter https://wiki.apache.org/jackrabbit/DavidsModel gefunden werden.
Sie sollten alles im Repository speichern, anstatt sich auf separate Datenquellen von Dritten wie etwa Datenbanken zu verlassen. Dies bezieht sich auf erstellte Inhalte, Binärdaten wie Bilder, Code und Konfigurationen. Auf diese Weise können Sie mit einem Satz von APIs alle Inhalte verwalten und die Promotion dieser Inhalte durch Replikation steuern. Außerdem profitieren Sie von nur einer einzigen Quelle für Backups, Protokollierung usw.
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 den standardmäßigen Zugriffskontrollen funktioniert, und vermeiden, dass unnötige Servlets im CRUD-Stil generiert werden.
Servlets sollten auf Basis von Ressourcentypen anstelle von Pfaden definiert werden. Dies ermöglicht die Verwendung von JCR-Zugriffskontrollen, die Einhaltung der REST-Prinzipien und die Verwendung des Ressourcen- und Ressourcenauflösers, der uns in der Anforderung zur Verfügung gestellt wird. Dies ermöglicht es uns auch, die Skripten zu ändern, die URLs auf dem Server wiedergeben, ohne URLs vom Client ändern zu müssen, während serverseitige Implementierungsdetails aus dem Client ausgeblendet werden, um zusätzliche Sicherheit zu gewährleisten.
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. Node-Typen entsprechen dem Schema im Repository und das Ändern von Node-Typen kann sehr teuer sein.
Durch die Einhaltung von Namenskonventionen wird die Konsistenz der Codebasis erhöht, die Fehler-Inzidenzrate gesenkt und der Arbeitsprozess der beteiligten Entwickler beschleunigt. Die folgenden Übereinkommen werden von der Adobe bei der Entwicklung von AEM verwendet:
Knotennamen
Eigenschaftsnamen
Komponenten (JSP/HTML)