Fundamentos técnicos de AEM :headding-anchor:aem-technical-foundations
AEM es una plataforma sólida basada en tecnologías probadas, escalables y flexibles. AEM AEM Este documento ofrece una descripción detallada de las distintas partes que componen la y está diseñado como un apéndice técnico para un desarrollador de paquetes de pila completa. No pretende ser una guía de introducción. AEM Si es nuevo en el desarrollo de la, consulte Introducción al desarrollo de AEM Sites - Tutorial de WKND como primer paso.
Aspectos básicos :headding-anchor:fundamentals
AEM Al ser un sistema moderno de gestión de contenidos, se basa en las tecnologías web estándar, que son:
- El ciclo de solicitud-respuesta (XMLHttpRequest / XMLHttpResponse)
- HTML
- CSS
- JavaScript
El repositorio de contenido subyacente y las capas de lógica empresarial se basan en las tecnologías Java™:
- JCR
- Sling
- OSGi
Repositorio de contenido de Java™ :headding-anchor:java-content-repository
El estándar del repositorio de contenido Java™ (JCR), JSR 283, especifica una forma independiente del proveedor e independiente de la implementación para acceder al contenido bidireccionalmente en un nivel granular dentro de un repositorio de contenido. El responsable de la especificación es Adobe Research (Suiza) AG.
El paquete JCR API 2.0, javax.jcr.*
, se usa para el acceso directo y la manipulación del contenido del repositorio.
AEM La se basa en un JCR.
Apache Jackrabbit Oak :headding-anchor:jackrabbit-oak
Apache Jackrabbit Oak es una implementación de un repositorio de contenido jerárquico escalable y de alto rendimiento que se usará como base de sitios web modernos de primera clase y otras aplicaciones de contenido exigentes, de conformidad con el estándar JCR.
Jackrabbit Oak (también denominado simplemente Oak AEM) es la implementación del estándar JCR en el que se basa la creación de la.
Procesamiento de solicitudes de Sling :headding-anchor:sling-request-processing
AEM Se ha creado usando Sling, un marco de aplicación web basado en principios REST que proporciona un fácil desarrollo de aplicaciones orientadas a contenido. Sling utiliza un repositorio JCR, como Apache Jackrabbit Oak, como almacén de datos. Sling ha sido colaborador de Apache Software Foundation; puede encontrar más información en Apache.
Introducción a Sling :headding-anchor:introduction-to-sling
Con Sling, el tipo de contenido que se procesará no es la primera consideración de procesamiento. En su lugar, la consideración principal es si la URL se resuelve en un objeto de contenido para el que se puede encontrar una secuencia de comandos para realizar la renderización. Este proceso proporciona un soporte excelente para que los autores de contenido web creen páginas que se personalicen fácilmente según sus necesidades.
Las ventajas de esta flexibilidad son evidentes en aplicaciones con una amplia gama de elementos de contenido diferentes o cuando necesita páginas que se puedan personalizar fácilmente. AEM En concreto, al implementar un sistema de administración de contenido web como, por ejemplo, la administración de contenido web, se puede hacer lo siguiente
Consulte Discover Sling en 15 minutos para conocer los primeros pasos para desarrollar con Sling.
El diagrama siguiente explica la resolución de scripts de Sling. Muestra cómo pasar de una solicitud HTTP al nodo de contenido, de un nodo de contenido al tipo de recurso, de un tipo de recurso al script y qué variables de script están disponibles.
En el diagrama siguiente se explican los parámetros de solicitud ocultos pero eficaces que se pueden usar con SlingPostServlet
, el controlador predeterminado para todas las solicitudes de POST. El controlador le ofrece un sinfín de opciones para crear, modificar, eliminar, copiar y mover nodos en el repositorio.
Sling se centra en el contenido :headding-anchor:sling-is-content-centric
Sling está centrado en contenido. Significa que el procesamiento se centra en el contenido, ya que cada solicitud (HTTP) se asigna al contenido en forma de recurso JCR (un nodo de repositorio):
- El primer destino es el recurso (nodo JCR) que contiene el contenido
- En segundo lugar, la representación o script se encuentra en las propiedades del recurso con determinadas partes de la solicitud (por ejemplo, los selectores o la extensión)
RESTful Sling :headding-anchor:restful-sling
Debido a su filosofía centrada en el contenido, Sling implementa un servidor orientado a REST y, por lo tanto, incluye un nuevo concepto en los marcos de aplicaciones web. Las ventajas son:
-
RESTful, no solo en la superficie; los recursos y las representaciones se modelan correctamente dentro del servidor
-
Quita uno o más modelos de datos
- Otros marcos de gestión de contenido pueden requerir una estructura URL, objetos empresariales o un esquema de base de datos para acceder a un recurso.
- El uso de Sling lo reduce a: URL = recurso = estructura JCR
Descomposición de URL :headding-anchor:url-decomposition
En Sling, el procesamiento se basa en la dirección URL de la solicitud del usuario. Define el contenido que se muestra mediante los scripts adecuados y la información se extrae de la dirección URL.
Análisis de la siguiente URL:
https://myhost/tools/spy.printable.a4.html/a/b?x=12
Puede dividirlo en sus partes compuestas:
https://
myhost
/
tools/spy
.printable.a4.
html
/
a/b
?
x=12
- protocolo - HTTPS
- host - Dominio del sitio
- ruta de contenido: ruta que especifica el contenido que se procesará y que se utilizará con la extensión. En este ejemplo, se traduce como
tools/spy.html
- selectores: se utilizan para métodos alternativos de representación del contenido; en este ejemplo, una versión compatible con la impresora en formato A4
- extensión - Formato de contenido; también especifica el script que se utilizará para la representación
- sufijo - Se puede usar para especificar información adicional
- params: cualquier parámetro necesario para el contenido dinámico
De la URL al contenido y los scripts :headding-anchor:from-url-to-content-and-scripts
Uso de los principios de descomposición de URL:
- La asignación utiliza la ruta de contenido extraída de la solicitud para localizar el recurso.
- Cuando se encuentra el recurso adecuado, se extrae el tipo de recurso de sling y se utiliza para localizar la secuencia de comandos que se utilizará para procesar el contenido.
La siguiente figura ilustra el mecanismo utilizado, que se analiza con más detalle en las secciones siguientes.
Con Sling, puede especificar qué script procesa una entidad determinada (estableciendo la propiedad sling:resourceType
en el nodo JCR). Este mecanismo ofrece más libertad que una en la que el script accede a las entidades de datos (como lo haría una instrucción SQL en un script PHP), ya que un recurso puede tener varias representaciones.
Asignación de solicitudes a los recursos :headding-anchor:mapping-requests-to-resources
La solicitud se desglosa y se extrae la información necesaria. Se busca el recurso solicitado en el repositorio (nodo de contenido):
- Primer Sling comprueba si existe un nodo en la ubicación especificada en la solicitud; por ejemplo,
../content/corporate/jobs/developer.html
- Si no se encuentra ningún nodo, se quitará la extensión y se repetirá la búsqueda; por ejemplo,
../content/corporate/jobs/developer
- Si no se encuentra ningún nodo, Sling devuelve el código http 404 (no encontrado).
Sling también permite que otros nodos que no sean nodos JCR sean recursos, pero esta funcionalidad es avanzada.
Localización del script :headding-anchor:locating-the-script
Cuando se encuentra el recurso apropiado (nodo de contenido), se extrae sling resource type. Esta ruta localiza el script que se utilizará para procesar el contenido.
La ruta especificada por sling:resourceType
puede ser:
- Absoluto
- Relativo a un parámetro de configuración
Todos los scripts de Sling se almacenan en subcarpetas de /apps
(scripts mutables, de usuario) o /libs
(scripts inmutables, del sistema), en las que se busca en este orden.
Otros puntos que hay que tener en cuenta son:
- Cuando se requiere el método (GET, POST), se especifica en mayúsculas según la especificación HTTP, por ejemplo,
jobs.POST.esp
- Se admiten varios motores de scripts, pero los scripts comunes recomendados son HTL y JavaScript.
AEM La lista de motores de scripts admitidos por la instancia determinada de se enumera en la consola de administración de Felix ( http://<host>:<port>/system/console/slingscripting
).
En el ejemplo anterior, si sling:resourceType
es hr/jobs
, para:
-
Solicitudes y direcciones URL de GET/HEAD que terminan en
.html
(tipos de solicitud predeterminados, formato predeterminado)- El script es
/apps/hr/jobs/jobs.esp
; la última sección desling:resourceType
forma el nombre del archivo.
- El script es
-
Solicitudes de POST (todos los tipos de solicitud excepto GET/HEAD, el nombre del método debe estar en mayúsculas)
- Se utiliza el POST en el nombre del script.
- El script es
/apps/hr/jobs/jobs.POST.esp
.
-
Direcciones URL en otros formatos, que no terminan con
.html
- Por ejemplo,
../content/corporate/jobs/developer.pdf
- El script es
/apps/hr/jobs/jobs.pdf.esp
; el sufijo se agrega al nombre del script.
- Por ejemplo,
-
URL con selectores
- Los selectores se pueden utilizar para mostrar el mismo contenido en un formato alternativo. Por ejemplo, una versión compatible con una impresora, una fuente RSS o un resumen.
- Si observa una versión compatible con la impresora donde el selector podría ser
print
; como en../content/corporate/jobs/developer.print.html
- El script es
/apps/hr/jobs/jobs.print.esp
; el selector se agrega al nombre del script.
-
Si no, se define
sling:resourceType
, entonces:- La ruta de contenido se usa para buscar un script apropiado (si está activo el script basado en rutas
ResourceTypeProvider
). - Por ejemplo, el script de
../content/corporate/jobs/developer.html
generaría una búsqueda en/apps/content/corporate/jobs/
. - Se utiliza el tipo de nodo principal.
- La ruta de contenido se usa para buscar un script apropiado (si está activo el script basado en rutas
-
Si no se encuentra ninguna secuencia de comandos, se utiliza la predeterminada.
- La representación predeterminada se admite como texto sin formato (
.txt
), HTML (.html
) y JSON (.json
), todos los cuales enumeran las propiedades del nodo (con el formato adecuado). La representación predeterminada para la extensión.res
, o solicitudes sin una extensión de solicitud, es poner en cola el recurso (cuando sea posible).
- La representación predeterminada se admite como texto sin formato (
-
Para la administración de errores de http (códigos 403 o 404), Sling busca una secuencia de comandos en:
- La ubicación
/apps/sling/servlet/errorhandler
para los scripts personalizados - O la ubicación del script estándar
/libs/sling/servlet/errorhandler/404.jsp
- La ubicación
Si se aplican varios scripts a una solicitud determinada, se selecciona el script con la mejor coincidencia. Cuanto más específica sea una coincidencia, mejor será; es decir, cuanto más coincida el selector, mejor, independientemente de la coincidencia de cualquier extensión de solicitud o nombre de método.
Por ejemplo, considere una solicitud de acceso al recurso
/content/corporate/jobs/developer.print.a4.html
Del tipo
sling:resourceType="hr/jobs"
Suponiendo que tiene la siguiente lista de scripts en la ubicación correcta:
GET.esp
jobs.esp
html.esp
print.esp
print.html.esp
print/a4.esp
print/a4/html.esp
print/a4.html.esp
Entonces el orden de preferencia sería (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1).
Además de los tipos de recursos (definidos principalmente por la propiedad sling:resourceType
), también está el supertipo de recursos. Este tipo se indica mediante la propiedad sling:resourceSuperType
. Estos supertipos también se tienen en cuenta al intentar encontrar una secuencia de comandos. La ventaja de los supertipos de recursos es que pueden formar una jerarquía de recursos en la que el tipo de recurso predeterminado sling/servlet/default
(utilizado por los servlets predeterminados) sea en realidad la raíz.
El supertipo de recurso de un recurso se puede definir de dos maneras:
- por la propiedad
sling:resourceSuperType
del recurso. - por la propiedad
sling:resourceSuperType
del nodo al que señalasling:resourceType
.
Por ejemplo:
-
/
-
a
-
b
sling:resourceSuperType = a
-
c
sling:resourceSuperType = b
-
x
sling:resourceType = c
-
y
sling:resourceType = c
sling:resourceSuperType = a
-
La jerarquía de tipo de:
/x
- Es
[ c, b, a, <default>]
- Es
- Mientras que para
/y
- La jerarquía es
[ c, a, <default>]
- La jerarquía es
El motivo se debe a que /y
tiene la propiedad sling:resourceSuperType
, mientras que /x
no la tiene y, por lo tanto, su supertipo se toma de su tipo de recurso.
Los scripts de Sling no se pueden llamar directamente :headding-anchor:sling-scripts-cannot-be-called-directly
En Sling, no se puede llamar directamente a los scripts porque rompería el concepto estricto de un servidor REST; mezclaría recursos y representaciones.
Si llama a la representación (la secuencia de comandos) directamente, oculta el recurso dentro de la secuencia de comandos, por lo que el marco de trabajo (Sling) ya no sabe nada de él. Por lo tanto, se pierden ciertas funciones:
-
Gestión automática de métodos http distintos de la GET, incluidos:
- POST, PUT, DELETE que se gestiona con una implementación predeterminada de sling
- El script
POST.jsp
en su ubicaciónsling:resourceType
-
Su arquitectura de código ya no es tan limpia ni está tan claramente estructurada como debería ser; es de suma importancia para el desarrollo a gran escala
API de Sling :headding-anchor:sling-api
Utiliza el paquete de API de Sling, org.apache.sling.*
y las bibliotecas de etiquetas.
Hacer referencia a elementos existentes mediante sling:include :headding-anchor:referencing-existing-elements-using-sling-include
Una consideración final es la necesidad de hacer referencia a los elementos existentes dentro de los guiones.
Los scripts más complejos (agregar scripts) tienen acceso a varios recursos (por ejemplo, navegación, barra lateral, pie de página y elementos de una lista) y lo hacen incluyendo el recurso.
En este caso, puede utilizar el comando sling:include("/<path>/<resource>")
. Incluye efectivamente la definición del recurso al que se hace referencia.
OSGi :headding-anchor:osgi
OSGi (Open Services Gateway Initiative) define una arquitectura para desarrollar e implementar aplicaciones y bibliotecas modulares (también se conoce como Dynamic Module System for Java™). Los contenedores OSGi le permiten dividir la aplicación en módulos individuales (son archivos jar con información meta adicional y llamados paquetes en la terminología OSGi) y administrar las dependencias cruzadas entre ellos con:
- Servicios implementados dentro del contenedor
- Un contrato entre el contenedor y la aplicación
Estos servicios y contratos proporcionan una arquitectura que permite a los elementos individuales descubrirse dinámicamente entre sí para colaborar.
A continuación, un marco OSGi le ofrece carga/descarga dinámica, configuración y control de estos paquetes, sin necesidad de reiniciarlos.
Esta arquitectura le permite ampliar Sling con módulos específicos de la aplicación. AEM Sling y, por lo tanto, la implementación de OSGi utiliza la implementación Apache Felix. Ambas son colecciones de paquetes OSGi que se ejecutan dentro de un marco OSGi.
Esta funcionalidad permite realizar las siguientes acciones en cualquiera de los paquetes de la instalación:
- Instalar
- Iniciar
- Detener
- Actualizar
- Desinstalar
- Ver estado más reciente
- Acceda a información más detallada sobre paquetes específicos, por ejemplo, nombre simbólico, versión y ubicación
Consulte Configuración de OSGi para AEM as a Cloud Service para obtener más información.
Estructura dentro del repositorio :headding-anchor:structure-within-the-repository
La siguiente lista ofrece información general sobre la estructura que se ve dentro del repositorio.
/apps
- Relacionado con la aplicación; incluye definiciones de componentes específicas del sitio web. Los componentes que desarrolle se pueden basar en los componentes predeterminados disponibles en/libs/core/wcm/components
./content
: contenido creado para su sitio web./etc
/home
- Información de usuario y grupo.- AEM
/libs
- Bibliotecas y definiciones que pertenecen al núcleo de la. AEM Las subcarpetas de/libs
representan las características de la aplicación listas para usar No se puede modificar el contenido de/libs
. Las características específicas del sitio web deben realizarse en/apps
. /tmp
- Área de trabajo temporal./var
: archivos que cambian y son actualizados por el sistema; como registros de auditoría, estadísticas y control de eventos.
/libs
. Para cambios de configuración y de otro tipo, copie el elemento de /libs
a /apps
y realice los cambios que desee en /apps
.