AEM Conceptos principales de aem-core-concepts

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

AEM Necesita las siguientes habilidades para desarrollar sobre la parte superior de la:

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

Repositorio de contenido de Java™ java-content-repository

El estándar Java™ Content Repository (JCR), JSR 283, especifica una forma independiente del proveedor y de la implementación de acceder al contenido bidireccionalmente en un nivel granular dentro de un repositorio de contenido.

El plomo de la especificación es poseído por Adobe Research (Suiza) AG.

El API 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

AEM El servidor de experiencia proporciona los servicios de experiencia en los que se basa la y que pueden utilizarse 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 2.0 de JCR.

Procesamiento de solicitudes de Sling sling-request-processing

Introducción a Sling introduction-to-sling

AEM se crea usando el Sling, un marco de trabajo de aplicaciones web basado en principios REST que proporciona un fácil desarrollo de aplicaciones orientadas a contenido. AEM Sling utiliza un repositorio JCR, como Apache Jackrabbit o, si existe, el repositorio de contenido CRX, como su repositorio de datos, en su caso, el repositorio de contenido CRX. Sling ha sido colaborador de Apache Software Foundation; puede encontrar más información en Apache.

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 responde a un objeto de contenido para el que se puede encontrar una secuencia de comandos para realizar la renderización. Esto proporciona una excelente compatibilidad 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 particular, al implementar un sistema de administración de contenido web como WCM en la solución de la aplicación de la interfaz de usuario de la aplicación de la aplicación de la solución de la aplicación de la solución de la aplicación de la plataforma de administración de contenido web.

Consulte Descubra 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 todos los parámetros de solicitud ocultos, pero útiles, que puede utilizar al trabajar con SlingPostServlet. Incluye el controlador predeterminado para todas las solicitudes de POST que le ofrece un sinfín de opciones para crear, modificar, eliminar, copiar y mover nodos en el repositorio.

Sling se centra 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):

RESTful Sling 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:

Descomposición de URL url-decomposition

En Sling, el procesamiento se basa en la dirección URL de la solicitud del usuario. Esto define el contenido que deben mostrar los scripts adecuados. Para ello, se extrae información de la dirección URL.

Si analiza la siguiente dirección URL:

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

Puede dividirlo en sus partes compuestas:

protocolo HTTP

host Nombre del sitio web.

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

selectores Se utiliza 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 del contenido; también especifica el script que se utilizará para el procesamiento.

sufijo Se puede utilizar para especificar información adicional.

parámetros Cualquier parámetro necesario para el contenido dinámico.

De la URL al contenido y los scripts from-url-to-content-and-scripts

Uso de estos principios:

La siguiente imagen ilustra el mecanismo utilizado, que se analiza con más detalle en las secciones siguientes.

Con Sling, puede especificar qué secuencia de comandos procesa una entidad determinada (configurando 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 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 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):

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

Localización del script locating-the-script

Cuando se encuentra el recurso adecuado (nodo de contenido), la variable tipo de recurso de sling se ha extraído. Esta es una ruta que localiza el script que se utilizará para procesar el contenido.

La ruta especificada por el sling:resourceType puede ser:

Todos los scripts de Sling se almacenan en subcarpetas de /apps o /libs, que se busca en este orden (consulte Personalizar componentes y otros elementos).

Otros puntos que hay que tener en cuenta son:

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).

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

En el ejemplo anterior, si la variable sling:resourceType es hr/jobs y luego para:

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
de tipo
sling:resourceType="hr/jobs"

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

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 el sling:resourceType propiedad), también está el supertipo de recurso. Esto se indica mediante la variable sling:resourceSuperType propiedad. 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 donde el tipo de recurso predeterminado es sling/servlet/default (utilizado por los servlets predeterminados) es en realidad la raíz.

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

Por ejemplo:

La jerarquía de tipo de:

Esto se debe a /y tiene el sling:resourceSuperType propiedad mientras 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

En Sling, no se puede 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, 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:

API de Sling sling-api

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

Hacer referencia a elementos existentes mediante 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 guiones.

Los scripts más complejos (agregar scripts) deben acceder a varios recursos (navegación, barra lateral, pie de página, elementos de una lista, por ejemplo) y hacerlo incluyendo la variable resource.

Para ello, utilice el sling:include("/<path>/<resource>"). Esto incluye 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 conoce como Sistema de módulos dinámicos para Java™). Los contenedores OSGi le permiten dividir la aplicación en módulos individuales (que son archivos jar con información meta adicional y llamados paquetes en la terminología OSGi) y administrar las dependencias cruzadas entre ellos con:

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. Sling, y por lo tanto CQ5, utiliza el Apache Felix Implementación de OSGI (iniciativa Open Services Gateway) y se basa en las especificaciones de la versión 4.2 de la plataforma de servicio OSGi. 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:

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

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

Los 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 Documentos de Java™ 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 procesamiento y otros datos.

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

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

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

Por ejemplo, para obtener las propiedades del nodo actual, puede utilizar el siguiente código en el script:

PropertyIterator properties = currentNode.getProperties();

CurrentNode es el objeto de nodo actual.

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

Widget AEM En todos los casos, los widgets administran la entrada del usuario. Suelen utilizarse para controlar la edición de un fragmento de contenido.

Los cuadros de diálogo se crean combinando widgets.

AEM Se ha desarrollado la biblioteca de widgets de ExtJS para utilizar.

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

AEM Para editar contenido, utiliza los cuadros de diálogo definidos por el desarrollador de la aplicación. Estos combinan una serie de widgets 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 para varias 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.

AEM Dentro de, 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 procesar contenido ni estar vinculado a un recurso específico. Por ejemplo, un componente de navegación muestra información sobre varios recursos.

La definición de un componente incluye lo siguiente:

Plantilla Una plantilla es la base de un tipo de página específico. Al crear una página en la pestaña Sitios web, el usuario debe seleccionar una plantilla. A continuación, 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 utilizado para procesar la página y el contenido predeterminado (contenido principal de nivel superior). AEM El contenido define cómo se procesa, ya que está centrado en el contenido.

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

Página Una página es una "instancia" de 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 señala 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 el script:

String pageName = currentPage.getName();

CurrentPage es el objeto de página actual. Para obtener más información sobre la manipulación de objetos Page, consulte la Documentos de Java™.

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

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

Página myPage = pageManager.getContainingPage(myResource);

PageManager, que es el objeto de administrador de páginas, y myResource, un objeto de recurso. Para obtener más información sobre los métodos proporcionados por el administrador de páginas, consulte la Documentos de Java™.

Estructura dentro del repositorio structure-within-the-repository

La siguiente lista ofrece información general sobre la estructura que se ve dentro del repositorio.

Entornos environments

AEM Con, un entorno de producción suele constar de dos tipos diferentes de instancias: y Instancias de autor y publicación.

Dispatcher the-dispatcher

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

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

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

Consulte la Herramienta FileVault 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 aprobación por parte de varios participantes. Estos procesos se pueden representar como flujos de trabajo, AEM definido y desarrollado dentro de la red dey luego se aplica a 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 la aplicación posterior al contenido.

Administración de varios sitios multi-site-management

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

Por ejemplo, los sitios web a menudo se ofrecen 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 de sincronización de contenido entre sitios. Sin embargo, cuando el número de sitios aumenta o cuando hay varios idiomas implicados, es más eficiente automatizar el proceso.

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