Arquitectura de contenido

Sigue el modelo de David

El Modelo de David fue escrito por David Nuescheler hace años, pero las ideas hoy son ciertas. Los principios principales del Modelo de David son los siguientes:

• Los datos van primero, la estructura después. Tal vez.
• Impulse la jerarquía de contenido, no permita que suceda.
• Los espacios de trabajo son para clone(), merge()y update().
• Cuidado con los hermanos del mismo nombre.
• Las referencias se consideran perjudiciales.
• Los archivos son archivos.
• Las identificaciones son malas.

El Modelo de David se puede encontrar en la wiki de Jackrabbit en https://wiki.apache.org/jackrabbit/DavidsModel.

Todo es contenido

Todo debe almacenarse en el repositorio en lugar de depender de fuentes de datos de terceros independientes, como las bases de datos. Esto se aplica al contenido creado, a los datos binarios como imágenes, código, configuraciones, etc. Esto nos permite utilizar un conjunto de API para administrar todo el contenido y administrar la promoción de este contenido mediante la replicación. También obtenemos una única fuente de backup, registro, etc.

Utilice el principio de diseño "modelo de contenido primero"

Al crear una nueva función, empiece siempre por diseñar primero la estructura de contenido JCR y, a continuación, consulte la lectura y escritura de su contenido utilizando los servlets Sling predeterminados. Esto le permitirá asegurarse de que la implementación funciona bien con los mecanismos de control de acceso predeterminados y le permitirá evitar la generación de servlets de estilo CRUD innecesarios.

Be RESTful

Los servlets deben definirse en función de resourceTypes en lugar de rutas. Esto permite utilizar los controles de acceso JCR, adherirse a los principios de REST y utilizar la resolución de recursos y recursos que se nos proporcionan en la solicitud. Esto también nos permite cambiar las secuencias de comandos que procesan direcciones URL en el servidor sin necesidad de cambiar ninguna dirección URL del lado del cliente, mientras que oculta los detalles de implementación del lado del servidor del cliente para mayor seguridad.

Evitar definir nuevos tipos de nodos

Los tipos de nodos funcionan a un nivel bajo en la capa de infraestructura y la mayoría de los requisitos se pueden cumplir utilizando un tipo de nodo sling:resourceType asignado a un tipo de nodo nt:unstructured, oak:Unstructured, sling:Folder o cq:Page. Los tipos de nodos equivalen a esquema en el repositorio y cambiar los tipos de nodos puede ser muy caro en el futuro.

Adherirse a las convenciones de nomenclatura en el JCR

El cumplimiento de las convenciones de nomenclatura aumentará la coherencia de la base de código, reduciendo la tasa de incidencia de defectos y aumentando la velocidad de los desarrolladores que trabajan en el sistema. El Adobe utiliza las siguientes convenciones para desarrollar AEM:

• Nombres de nodo

  • Todas las minúsculas
  • Separación de palabras mediante guiones

• Nombres de propiedades

  • Maleta de camello, comenzando por una letra en minúscula

• Componentes (JSP/HTML)

  • Todas las minúsculas
  • Separación de palabras mediante guiones

Recursos de Business.Adobe.com

Multichannel Communication Automated Onboarding Style System Personalized Experiences Content As A Service Digital Signage