Integración de JCR

Preferir la API de recursos de Sling a la API de JCR

La API de Sling funciona en un nivel más alto y abstracto que la API de JCR. Esto permite que el código sea más reutilizable e independiente del almacenamiento subyacente. Esto facilita la inclusión de datos virtuales externos a través del mecanismo ResourceProvider si es necesario.

Evite consultas siempre que sea posible

Siempre es más rápido navegar por el repositorio para recuperar datos que ejecutar una consulta. Hay casos en los que serán necesarias consultas, como una consulta de usuario final o la necesidad de encontrar contenido estructurado en todo el repositorio, pero en todos los demás casos, es preferible navegar a los nodos necesarios. Siempre se deben evitar consultas en la lógica de procesamiento, como componentes de navegación, una "lista de elementos recientes", recuentos de elementos, etc. En estos casos, es mejor recorrer la jerarquía o prealmacenar el resultado para que se pueda utilizar directamente cuando se procese.

Restringir el alcance de la observación JCR

Al escuchar eventos en el repositorio, es importante reducir el ámbito tanto como sea posible. Por ejemplo, es mucho mejor escuchar un evento en /etc/mycompany que en /etc. Nunca escuche eventos en la raíz del repositorio. Además, asegúrese de que los métodos de llamada de retorno se ejecutan lo más rápido posible cuando no hay nada que hacer.

Elimine el uso del acceso de administración de JCR

A partir del AEM 6, el inicio de sesión en Administración ha quedado obsoleto, al igual que obtener una sesión administrativa de ResourceResolverFactory. En su lugar, se deben crear cuentas de servicio para las operaciones de back-office que requieran este tipo de acceso y ResourceResolverFactory se puede utilizar para obtener un ResourceResolver para esta cuenta.