Actualizaciones sostenibles sustainable-upgrades
Marco de personalización customization-framework
Arquitectura (funcional/infraestructura/contenido/aplicación) architecture-functional-infrastructure-content-application
La función Marco de personalización está diseñada para ayudar a reducir las infracciones en áreas no ampliables del código (como las API) o en contenido (como las superposiciones) que no son compatibles con la actualización.
Hay dos componentes en el marco de personalización: la superficie de API y la clasificación de contenido.
Superficie API api-surface
En versiones anteriores de Adobe Experience Manager (AEM), muchas API se exponían a través de Uber Jar. Algunas de estas API no estaban pensadas para que las usaran los clientes, pero estaban expuestas a admitir la funcionalidad de AEM en todos los paquetes. En adelante, las API de Java™ se marcarán como Públicas o Privadas para indicar a los clientes qué API son seguras de usar en el contexto de las actualizaciones. Otros detalles específicos incluyen:
-
Los paquetes de implementación personalizada pueden usar y hacer referencia a las API de Java™ marcadas como
Public. -
Las API públicas son compatibles con la instalación de un paquete de compatibilidad.
-
El paquete de compatibilidad contiene una compatibilidad con Uber JAR para garantizar la compatibilidad con versiones anteriores
-
Las API de Java™ marcadas como
Privateestán pensadas para que solo las usen los paquetes internos de AEM, no los paquetes personalizados.
Private y Public en este contexto no debe confundirse con las nociones de Java™ de clases públicas y privadas.
Clasificaciones de contenido content-classifications
AEM ha utilizado durante mucho tiempo el principal de las superposiciones y la fusión de recursos de Sling para permitir a los clientes ampliar y personalizar la funcionalidad de AEM. La funcionalidad predefinida que alimenta las consolas y la interfaz de usuario de AEM se almacena en /libs. Los clientes nunca modificarán nada por debajo de /libs, pero podrían agregar contenido adicional por debajo de /apps para superponer y ampliar la funcionalidad definida en /libs (consulte Desarrollo con superposiciones para obtener más información). Esto seguía causando numerosos problemas al actualizar AEM, ya que el contenido de /libs podía cambiar y provocar que la funcionalidad de superposición se interrumpiera de formas inesperadas. Los clientes también podrían extender los componentes de AEM mediante herencia mediante sling:resourceSuperType o simplemente hacer referencia a un componente de /libs directamente mediante sling:resourceType. Pueden producirse problemas de actualización similares con los casos de uso de referencia y anulación.
Para que sea más seguro y fácil para los clientes comprender qué áreas de /libs son seguras de usar y superponer, el contenido de /libs se ha clasificado con los siguientes mixins:
-
Público (granite:PublicArea): define un nodo como público para que se pueda superponer, heredar (
sling:resourceSuperType) o usar directamente (sling:resourceType). Los nodos debajo de /libs marcados como Public son seguros para actualizar con la adición de un Paquete de compatibilidad. En general, los clientes solo deben utilizar nodos marcados como Public. -
Abstracto (granito:AbstractArea): define un nodo como abstracto. Los nodos se pueden superponer o heredar (
sling:resourceSupertype), pero no se pueden usar directamente (sling:resourceType). -
Final (granite:FinalArea): define un nodo como final. Los nodos clasificados como finales no se deben superponer ni heredar. Los nodos finales se pueden usar directamente mediante
sling:resourceType. Los subnodos bajo el nodo final se consideran internos de forma predeterminada. -
Interno (granite:InternalArea) *- *Define un nodo como interno. Los nodos clasificados como internos no deben superponerse, heredarse ni utilizarse directamente. Estos nodos solo están pensados para la funcionalidad interna de AEM
-
Sin anotación: los nodos heredan la clasificación según la jerarquía del árbol. La raíz / es de forma predeterminada pública. Los nodos con un nodo principal clasificado como Interno o Final también se tratarán como Interno.
Internal, pero podrían utilizarse con la inclusión clientlib estándar. Es importante que un cliente siga respetando la clasificación interna en estos casos.Indicadores de tipo de contenido CRXDE Lite crxde-lite-content-type-indicators
Las mezclas aplicadas en CRXDE Lite muestran nodos y árboles de contenido que están marcados como INTERNAL como atenuados (atenuados). Para FINAL, solo el icono está atenuado. Los elementos secundarios de estos nodos también aparecen atenuados. La funcionalidad Nodo de superposición está desactivada en ambos casos.
Público
Final
Interno
Comprobación de estado del contenido
AEM 6.5 se envía con una comprobación de estado para alertar a los clientes de si el contenido superpuesto o referenciado se utiliza de una manera incoherente con la clasificación de contenido.
La Comprobación de acceso al contenido de Sling/Granite es una nueva comprobación de estado que supervisa el repositorio para ver si el código del cliente accede incorrectamente a los nodos protegidos en AEM.
Esto explora /apps y, por lo general, tarda varios segundos en completarse.
Para acceder a esta nueva comprobación de estado, haga lo siguiente:
-
En la pantalla de inicio de AEM, vaya a Herramientas > Operaciones > Informes de estado
-
Haga clic en Comprobación de acceso al contenido de Sling/Granite.
Una vez finalizado el análisis, aparece una lista de advertencias que notifican al usuario final del nodo protegido al que se hace referencia incorrectamente:
Después de corregir las infracciones, vuelve al estado verde:
La comprobación de estado muestra información recopilada por un servicio en segundo plano que comprueba asincrónicamente cada vez que se utiliza una superposición o un tipo de recurso en todas las rutas de búsqueda de Sling. Si los mixins de contenido se utilizan incorrectamente, informa de una infracción.