AEM Conceptos principales aem-core-concepts

CAUTION
AEM 6.4 ha llegado al final de la compatibilidad ampliada y esta documentación ya no se actualiza. Para obtener más información, consulte nuestra períodos de asistencia técnica. Buscar las versiones compatibles here.
NOTE
Antes de profundizar en los conceptos básicos de AEM, Adobe recomienda completar el tutorial de WKND en la Introducción al desarrollo de AEM Sites documento para obtener una descripción general del proceso de desarrollo de AEM e introducción a los conceptos básicos.

Requisitos previos para el desarrollo en AEM prerequisites-for-developing-on-aem

Necesitará las siguientes habilidades para desarrollar sobre AEM:

  • Conocimientos básicos de las técnicas de aplicación web, incluidos:

    • ciclo request -response (XMLHttpRequest / XMLHttpResponse)
    • HTML
    • CSS
    • JavaScript
  • Conocimientos prácticos de Experience Server (CRX), incluido el Explorador de contenido

  • Para desarrollar en la IU clásica, también se requiere conocimiento básico de JSP (páginas de JavaServer), incluida la capacidad de comprender y modificar ejemplos JSP simples.

También se recomienda que lea y siga el Directrices y prácticas recomendadas.

Repositorio de contenido Java 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 de 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.

La variable API de JCR 2.0 paquete, javax.jcr.* se utiliza para el acceso directo y la manipulación del contenido del repositorio.

Experience Server (CRX) y Jackrabbit experience-server-crx-and-jackrabbit

Experience Server proporciona los servicios de Experience AEM que se han creado y que se pueden aprovechar para crear aplicaciones personalizadas, e incrusta el repositorio de contenido basado en Jackrabbit.

Apache Jackrabbit es una implementación de código abierto, totalmente conforme, de la API JCR 2.0.

Procesamiento de solicitudes de Sling sling-request-processing

Introducción a Sling introduction-to-sling

AEM se crea mediante Sling, un marco de aplicaciones web basado en los principios de REST que proporciona un fácil desarrollo de aplicaciones orientadas al contenido. Sling utiliza un repositorio JCR, como Apache Jackrabbit, o en el caso de AEM, el Repositorio de Contenido CRX, como su almacén de datos. Sling ha sido contribuido a la Apache Software Foundation - puede encontrar más información en Apache.

Con Sling, el tipo de contenido que se va a 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. Esto proporciona una excelente compatibilidad a los autores de contenido web para crear páginas que se adapten fácilmente a 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. En particular, al implementar un sistema de administración de contenido web como WCM en la solución AEM.

Consulte Descubra Sling en 15 minutos para los primeros pasos para el desarrollo con Sling.

En el diagrama siguiente se explica la resolución del script Sling: muestra cómo pasar de una solicitud HTTP al nodo de contenido, de un nodo de contenido a un tipo de recurso, de un tipo de recurso a un script y qué variables de secuencias de comandos están disponibles.

chlimage_1-84

En el diagrama siguiente se explican todos los parámetros de solicitud ocultos pero poderosos que puede utilizar al tratar con SlingPostServlet, el controlador predeterminado para todas las solicitudes de POST que le ofrece infinitas opciones para crear, modificar, eliminar, copiar y mover nodos en el repositorio.

chlimage_1-85

Sling es centrado en el contenido sling-is-content-centric

Sling es centrado en el contenido. Esto 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 la secuencia de comandos se encuentran en las propiedades del recurso en combinación con ciertas partes de la solicitud (por ejemplo, selectores o la extensión)

Sling RESTful restful-sling

Debido a la 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:

  • muy RESTful, no solo en la superficie; los recursos y las representaciones están modelados correctamente dentro del servidor

  • elimina uno o varios modelos de datos

    • anteriormente se necesitaban las siguientes opciones: estructura URL, objetos empresariales, esquema de base de datos;
    • ahora se reduce a: URL = recurso = estructura JCR

Descomposición de URL url-decomposition

En Sling, el procesamiento se controla mediante la dirección URL de la solicitud del usuario. Define el contenido que se mostrará en las secuencias de comandos correspondientes. Para ello, la información se extrae de la dirección URL.

Si analizamos la siguiente URL:

https://myhost/tools/spy.printable.a4.html/a/b?x=12

Podemos dividirla en sus partes compuestas:

protocol
host
ruta de contenido
selector(s)
Extensión
sufijo
param(s)
https://
myhost
herramientas/espía
.printable.a4.
html
/
a/b
?
x=12

protocol HTTP

host Nombre del sitio web.

ruta de contenido Ruta que especifica el contenido que se va a procesar. se utiliza en combinación con la extensión; en este ejemplo traducen a tools/spy.html.

selector(s) Se utiliza para métodos alternativos de renderización del contenido; en este ejemplo, una versión compatible con impresora en formato A4.

Extensión Formato del contenido; también especifica la secuencia de comandos que se utilizará para la renderización.

sufijo Se puede utilizar para especificar información adicional.

param(s) Cualquier parámetro necesario para el contenido dinámico.

De URL a contenido y secuencias de comandos from-url-to-content-and-scripts

Con estos principios:

  • 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 sling y se utiliza para localizar la secuencia de comandos que se utilizará para procesar el contenido

En la figura siguiente se ilustra el mecanismo utilizado, que se examinará con más detalle en las secciones siguientes.

chlimage_1-86

Con Sling, se especifica qué secuencia de comandos procesa una entidad determinada (estableciendo la variable 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 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 mapping-requests-to-resources

La solicitud se desglosa y se extrae la información necesaria. Se busca en el repositorio el recurso solicitado (nodo de contenido):

  • el primer Sling comprueba si existe un nodo en la ubicación especificada en la solicitud; p. ej. ../content/corporate/jobs/developer.html
  • si no se encuentra ningún nodo, se abandona la extensión y se repite la búsqueda; p. ej. ../content/corporate/jobs/developer
  • si no se encuentra ningún nodo, Sling devolverá el código http 404 (no encontrado).

Sling también permite que otras cosas que no sean nodos JCR sean recursos, pero esta es una característica avanzada.

Localización de la secuencia de comandos locating-the-script

Cuando se encuentra el recurso apropiado (nodo de contenido), la variable tipo de recurso sling se extrae. Esta es una ruta, que localiza la secuencia de comandos que se utilizará para procesar el contenido.

La ruta especificada por la variable sling:resourceType puede ser:

  • absoluto

  • relativo, a un parámetro de configuración

    Las rutas relativas se recomiendan por Adobe, ya que aumentan la portabilidad.

Todos los scripts Sling se almacenan en subcarpetas de /apps o /libs, que se buscarán en este orden (consulte Personalización de componentes y otros elementos).

Otros puntos a tener en cuenta son:

  • cuando el método (GET, POST) sea obligatorio, se especificará en mayúsculas según la especificación HTTP, por ejemplo jobs.POST.esp (ver a continuación)

  • se admiten varios motores de secuencia de comandos:

    • .esp, .ecma: Páginas de ECMAScript (JavaScript) (ejecución del lado del servidor)
    • .jsp: Páginas del servidor Java (ejecución del lado del servidor)
    • .java: Compilador de servlets de Java (ejecución del lado del servidor)
    • .jst: Plantillas JavaScript (ejecución del lado del cliente)

La lista de motores de secuencia de comandos admitidos por la instancia de AEM dada se muestra en la Consola de administración Felix ( http://<host>:<port>/system/console/slingscripting).

Además, Apache Sling admite la integración con otros motores de secuencias de comandos populares (por ejemplo, Groovy, JRuby, Freemarker) y proporciona una forma de integrar nuevos motores de secuencias de comandos.

Si se utiliza el ejemplo anterior, si la variable sling:resourceType es hr/jobs a continuación, para:

  • solicitudes de GET/HEAD y direcciones URL que terminan en .html (tipos de solicitud predeterminados, formato predeterminado)

    El script será /apps/hr/jobs/jobs.esp; la última sección de sling:resourceType forma el nombre del archivo.

  • solicitudes del POST (todos los tipos de solicitud, excepto el GET/HEAD, el nombre del método debe estar en mayúsculas)

    se utilizará el POST en el nombre de la secuencia de comandos.

    La secuencia de comandos será /apps/hr/jobs/jobs.POST.esp.

  • URL en otros formatos, sin terminar con .html

    Por ejemplo ../content/corporate/jobs/developer.pdf

    La secuencia de comandos será /apps/hr/jobs/jobs.pdf.esp; el sufijo se agrega al nombre de la secuencia de comandos.

  • Direcciones URL con selectores

    Los selectores pueden utilizarse para mostrar el mismo contenido en un formato alternativo. Por ejemplo, una versión compatible con la impresora, una fuente rss o un resumen.

    Si miramos una versión fácil de imprimir en la que el selector podría estar print; como en ../content/corporate/jobs/developer.print.html

    La secuencia de comandos será /apps/hr/jobs/jobs.print.esp; el selector se agrega al nombre de la secuencia de comandos.

  • Si no se ha definido ningún sling:resourceType , entonces:

    • la ruta de contenido se utilizará para buscar una secuencia de comandos adecuada (si la ruta basada en ResourceTypeProvider está activa).

      Por ejemplo, la secuencia de comandos para ../content/corporate/jobs/developer.html generaría una búsqueda en /apps/content/corporate/jobs/.

    • se utilizará el tipo de nodo principal.

  • Si no se encuentra ningún script, se utilizará el script predeterminado.

    Actualmente, la representación predeterminada se admite como texto sin formato (.txt), HTML (.html) y JSON (.json), todos los cuales enumerarán las propiedades del nodo (con el formato adecuado). La representación predeterminada para la extensión .res, o solicitudes sin extensión de solicitud, es agrupar el recurso (siempre que sea posible).

  • Para la gestión de errores http (códigos 403 o 404) Sling buscará un script en:

    • la ubicación /apps/sling/servlet/errorhandler para secuencias de comandos personalizadas
    • o la ubicación de los scripts estándar /libs/sling/servlet/errorhandler/403.esp, o 404.esp respectivamente.

Si se aplican varios scripts para una solicitud determinada, se selecciona el script con la mejor coincidencia. Cuanto más específica sea una coincidencia, mejor será; en otras palabras, cuanto más selector coincida, mejor, independientemente de cualquier extensión de solicitud o coincidencia de nombre de método.

Por ejemplo, considere una solicitud para acceder al recurso
/content/corporate/jobs/developer.print.a4.html
de tipo
sling:resourceType="hr/jobs"

Suponiendo que tengamos la siguiente lista de scripts en la ubicación correcta:

  1. GET.esp
  2. jobs.esp
  3. html.esp
  4. print.esp
  5. print.html.esp
  6. print/a4.esp
  7. print/a4/html.esp
  8. 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 recurso (definidos principalmente por la variable sling:resourceType propiedad) también está el supertipo de recurso. Esto suele indicarse en el sling:resourceSuperType propiedad. Estos supertipos también se tienen en cuenta al intentar encontrar un script. La ventaja de los supertipos de recursos es que pueden formar una jerarquía de recursos donde el tipo de recurso predeterminado sling/servlet/default (utilizado por los servlets predeterminados) es efectivamente la raíz.

El supertipo de recurso de un recurso se puede definir de dos formas:

  • por sling:resourceSuperType propiedad del recurso.
  • por sling:resourceSuperType propiedad del nodo en el que sling:resourceType puntos.

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>]
  • while para /y
    • la jerarquía es [ c, a, <default>]

Esto se debe a que /y tiene la variable sling:resourceSuperType propiedad que /x no y, por lo tanto, su supertipo se toma de su tipo de recurso.

Los scripts de Sling no se pueden llamar directamente sling-scripts-cannot-be-called-directly

Dentro de Sling, no se pueden llamar directamente a los scripts, ya que esto 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, oculte el recurso dentro de la secuencia de comandos, de modo que la estructura (Sling) ya no lo sepa. Por lo tanto, se pierden algunas funciones:

  • administración automática de métodos http distintos de la GET, que incluyen:

    • POST, PUT y DELETE que se administran con una implementación predeterminada de sling
    • el POST.jsp secuencia de comandos en la ubicación sling:resourceType
  • su arquitectura de código ya no es tan limpia ni está tan claramente estructurada como debería ser; de gran importancia para el desarrollo a gran escala

API Sling sling-api

Utiliza el paquete de la API de Sling, org.apache.sling.Bibliotecas de etiquetas * y .

Referencia a elementos existentes utilizando sling:include referencing-existing-elements-using-sling-include

Una consideración final es la necesidad de hacer referencia a los elementos existentes dentro de los scripts.

Es posible que las secuencias de comandos más complejas (adición de secuencias de comandos) necesiten acceder a varios recursos (por ejemplo, navegación, barra lateral, pie de página y elementos de una lista) y hacerlo incluyendo la variable recurso.

Para ello, puede utilizar el sling:include("/<path>/<resource>"). Esto incluirá efectivamente la definición del recurso al que se hace referencia, como en la siguiente instrucción que hace referencia a una definición existente para procesar imágenes:

%><sling:include resourceType="geometrixx/components/image/img"/><%

OSGI osgi

OSGi define una arquitectura para desarrollar e implementar aplicaciones y bibliotecas modulares (también se denomina Sistema de módulos dinámicos para Java). Los contenedores OSGi le permiten dividir su aplicación en módulos individuales (son archivos jar con información meta adicional y llamados paquetes en terminología OSGi) y administrar las dependencias cruzadas entre ellos con:

  • servicios implementados dentro del contenedor
  • un contrato entre el contenedor y su solicitud

Estos servicios y contratos proporcionan una arquitectura que permite a los elementos individuales descubrirse entre sí de forma dinámica para la colaboración.

A continuación, un marco OSGi le ofrece carga/descarga dinámica, configuración y control de estos paquetes, sin necesidad de reiniciar.

NOTE
Puede encontrar información completa sobre la tecnología OSGi en la Sitio web de OSGi.
En particular, su página de Educación Básica contiene una colección de presentaciones y tutoriales.

Esta arquitectura le permite ampliar Sling con módulos específicos de aplicaciones. Sling, y por lo tanto CQ5, utiliza la variable Apache Felix la implementación de OSGI (Open Services Gateway) y se basa en las especificaciones de la versión 4.2 de OSGi Service Platform. Ambas son colecciones de paquetes OSGi que se ejecutan dentro de un marco OSGi.

Esto le permite realizar las siguientes acciones en cualquiera de los paquetes de la instalación:

  • instalar
  • start
  • stop
  • actualizar
  • desinstalar
  • ver el estado actual
  • acceda a información más detallada (por ejemplo, nombre simbólico, versión, ubicación, etc.) sobre los paquetes específicos

Consulte la consola web, Configuración OSGI y Ajustes de configuración de OSGi para obtener más información.

Objetos de desarrollo en el entorno de AEM development-objects-in-the-aem-environment

Las siguientes son de interés para el desarrollo:

Elemento Un elemento es un nodo o una propiedad.

Para obtener información detallada sobre la manipulación de objetos Item, consulte la Javadocs de la interfaz javax.jcr.Item

Nodo (y sus propiedades) Los nodos y sus propiedades se definen en la especificación JCR API 2.0 (JSR 283). Almacenan contenido, definiciones de objetos, secuencias de comandos de renderización y otros datos.

Los nodos definen la estructura de contenido y sus propiedades almacenan el contenido real y los metadatos.

Los nodos de contenido dirigen el procesamiento. Sling obtiene el nodo de contenido de la solicitud entrante. La propiedad sling:resourceType de este nodo apunta al componente de renderización Sling que se va a utilizar.

Un nodo, que es un nombre JCR, también se denomina recurso en el entorno Sling.

Por ejemplo, para obtener las propiedades del nodo actual, puede utilizar el siguiente código en la secuencia de comandos:

PropertyIterator properties = currentNode.getProperties();

Con currentNode siendo el objeto node actual.

Para obtener más información sobre la manipulación de objetos Node, consulte la Javadocs.

Widget En AEM todas las entradas del usuario están administradas por widgets. A menudo se utilizan para controlar la edición de un fragmento de contenido.

Los cuadros de diálogo se crean combinando utilidades.

AEM ha sido desarrollado utilizando la biblioteca de widgets de ExtJS.

Diálogo Un cuadro de diálogo es un tipo especial de utilidad.

Para editar contenido, AEM utiliza los cuadros de diálogo definidos por el desarrollador de la aplicación. Combinan una serie de utilidades para presentar al usuario todos los campos y acciones necesarios para editar el contenido relacionado.

Los cuadros de diálogo también se utilizan para editar metadatos y por diversas herramientas administrativas.

Componente Un componente de software es un elemento del sistema que ofrece un servicio o evento predefinido y que puede comunicarse con otros componentes.

En AEM, un componente se utiliza a menudo para representar el contenido de un recurso. Cuando el recurso es una página, el componente que lo procesa se denomina componente de nivel superior o componente de página. Sin embargo, un componente no tiene que representar contenido ni estar vinculado a un recurso específico; por ejemplo, un componente de navegación mostrará información sobre varios recursos.

La definición de un componente incluye:,

  • el código utilizado para procesar el contenido
  • un cuadro de diálogo para la entrada del usuario y la configuración del contenido resultante.

Plantilla Una plantilla es la base de un tipo específico de página. Al crear una página en la ficha Sitios web , el usuario debe seleccionar una plantilla. La nueva página se crea copiando esta plantilla.

Una plantilla es una jerarquía de nodos que tiene la misma estructura que la página que se va a crear, pero sin contenido real.

Define el componente de página que se utiliza para procesar la página y el contenido predeterminado (contenido principal de nivel superior). El contenido define cómo se procesa como AEM está centrado en el contenido.

Componente de página (componente de nivel superior) Componente que se utilizará para procesar la página.

Página Una página es una "instancia" de una plantilla.

Una página tiene un nodo de jerarquía de tipo cq:Page y un nodo de contenido de tipo cq:PageContent. La propiedad sling:resourceType del nodo de contenido apunta al componente de página utilizado para procesar la página.

Por ejemplo, para obtener el nombre de la página actual, puede utilizar el siguiente código en la secuencia de comandos:

String pageName = currentPage.getName();

Con currentPage como el objeto de página actual. Para obtener más información sobre la manipulación de objetos de página, consulte la sección Javadocs.

Administrador de páginas El administrador de páginas es una interfaz que proporciona métodos para las operaciones a nivel de página.

Por ejemplo, para obtener la página contenedora de un recurso, puede utilizar el siguiente código en el script:

Page myPage = pageManager.getContainPage(myResource);

Con pageManager como el objeto de administrador de páginas y myResource como un objeto de recurso. Para obtener más información sobre los métodos proporcionados por el administrador de páginas, consulte la Javadocs.

Estructura dentro del repositorio structure-within-the-repository

La siguiente lista ofrece una descripción general de la estructura que verá dentro del repositorio.

CAUTION
Los cambios en esta estructura, o en los archivos que contiene, deben realizarse con cuidado.
Los cambios son necesarios cuando se desarrolla, pero debe asegurarse de comprender plenamente las implicaciones de cualquier cambio que realice.
CAUTION
No debe cambiar nada en la variable /libs ruta. Para cambios de configuración y otros cambios, copie el elemento de /libs a /apps y realice cualquier cambio dentro de /apps.
  • /apps

    Aplicación relacionada; incluye definiciones de componentes específicas del sitio web. Los componentes que desarrolle pueden basarse en los componentes integrados disponibles en /libs/foundation/components.

  • /content

    Contenido creado para el sitio web.

  • /etc

  • /home

    Información de usuarios y grupos.

  • /libs

    Bibliotecas y definiciones que pertenecen al núcleo de AEM. Las subcarpetas de /libs representan las funciones de AEM listas para usar como, por ejemplo, búsqueda o replicación. El contenido de /libs no debe modificarse, ya que afecta a la forma en que AEM funciona. Las funciones específicas de su sitio web deben desarrollarse en /apps (consulte Personalización de componentes y otros elementos).

  • /tmp

    Área de trabajo temporal.

  • /var

    Archivos que cambian y son actualizados por el sistema; como registros de auditoría, estadísticas y gestión de eventos.

Entornos environments

Con AEM, un entorno de producción a menudo consta de dos tipos diferentes de instancias: an Creación y publicación de instancias.

Dispatcher the-dispatcher

Dispatcher es la herramienta de Adobe tanto para el almacenamiento en caché como para el equilibrio de carga. Encontrará más información en Dispatcher.

FileVault (sistema de revisión de la fuente) filevault-source-revision-system

FileVault proporciona su repositorio JCR con asignación de sistemas de archivos y control de versiones. Se puede utilizar para administrar AEM proyectos de desarrollo con compatibilidad total para almacenar y versionar código de proyecto, contenido, configuraciones, etc., en sistemas de control de versiones estándar (por ejemplo, Subversion).

Consulte la Herramienta FileVault documentación para obtener información detallada.

Flujos de trabajo workflows

El contenido suele estar sujeto a procesos organizativos, incluidos pasos como la aprobación y la desactivación por parte de varios participantes. Estos procesos pueden representarse como flujos de trabajo, definida y desarrollada dentro de AEMy, a continuación, se aplican a la variable páginas de contenido apropiadas o recursos digitales según sea necesario.

El motor de flujo de trabajo se utiliza para administrar la implementación de los flujos de trabajo y su aplicación posterior al contenido.

Administración de varios sitios multi-site-management

Multi Site Manager (MSM) le permite administrar fácilmente varios sitios web que comparten contenido común. MSM permite definir relaciones entre los sitios para que los cambios de contenido en un sitio se replicen automáticamente en otros.

Por ejemplo, los sitios web se proporcionan a menudo en varios idiomas para audiencias internacionales. Cuando el número de sitios en el mismo idioma es bajo (de tres a cinco), es posible realizar un proceso manual para sincronizar el contenido entre sitios. Sin embargo, tan pronto como el número de sitios crece o cuando hay varios idiomas involucrados, se vuelve más eficiente automatizar el proceso.

  • Administre de manera eficiente versiones de diferentes idiomas de un sitio web.

  • Actualizar automáticamente uno o más sitios según un sitio de origen:

    • Aplique una estructura de base común y utilice contenido común en varios sitios.
    • Maximice el uso de los recursos disponibles.
    • Mantenga un aspecto común.
    • Enfoque los esfuerzos en la administración del contenido que difiere entre los sitios.

Para obtener más información, consulte Administrador de varios sitios.

recommendation-more-help
2315f3f5-cb4a-4530-9999-30c8319c520e