Integración de JCR

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

La API de Sling funciona a 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. Existen casos en los que las consultas serán necesarias, como una consulta del usuario final o la necesidad de encontrar contenido estructurado de todo el repositorio, pero para todos los demás casos, se prefiere navegar a los nodos necesarios. Las consultas siempre deben evitarse en la lógica de renderización, como los componentes de navegación, una "lista de elementos recientes", recuentos de elementos, etc. En estos casos, es mejor pasar por la jerarquía o prealmacenar en caché el resultado para que se pueda utilizar directamente cuando se represente.

Restringir el alcance de la observación JCR

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

Eliminación del uso del acceso de administrador JCR

A partir del AEM 6, el inicio de sesión en Administración ha quedado obsoleto, al igual que la obtención de 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 se puede usar ResourceResolverFactory para obtener un ResourceResolver para esta cuenta.

En esta página