En este capítulo analizaremos la relación entre un componente de página base y plantillas editables. Crearemos una plantilla de artículo desdiseñada basada en algunas maquetas de AdobeXD. En el proceso de creación de la plantilla, se tratan los componentes principales y las configuraciones de política avanzadas de las plantillas editables.
Revise las herramientas e instrucciones necesarias para configurar un entorno de desarrollo local.
Si ha completado correctamente el capítulo anterior, puede volver a utilizar el proyecto y omitir los pasos para extraer el proyecto de inicio.
Consulte el código de línea base sobre el que se basa el tutorial:
Consulte la tutorial/pages-templates-start
ramificación desde GitHub
$ cd ~/code/aem-guides-wknd
$ git checkout tutorial/pages-templates-start
Implemente código base en una instancia de AEM local con sus habilidades con Maven:
$ mvn clean install -PautoInstallSinglePackage
Si utiliza AEM 6.5 o 6.4, añada la variable classic
perfil a cualquier comando Maven.
$ mvn clean install -PautoInstallSinglePackage -Pclassic
Siempre puede ver el código terminado en GitHub o desproteja el código localmente cambiando a la rama tutorial/pages-templates-solution
.
En esta parte del tutorial, creará una nueva plantilla de página de artículo que se puede utilizar para crear páginas de artículos nuevas y se ajusta a una estructura común. La plantilla de página de artículos se basará en diseños y en un kit de interfaz de usuario creado en Adobe XD. Este capítulo se centra únicamente en la construcción de la estructura o el esqueleto de la plantilla. No se implementará ningún estilo, pero la plantilla y las páginas funcionarán.
En la mayoría de los casos, la planificación de un nuevo sitio web comienza con maquetas y diseños estáticos. Adobe XD es una herramienta de diseño que crea experiencias de usuario. A continuación, analizaremos un kit de IU y maquetas para ayudar a planificar la estructura de la plantilla de página de artículos.
Descargue el Archivo de diseño de artículo WKND.
Un genérico AEM Kit de interfaz de usuario de componentes principales también está disponible como punto de partida para proyectos personalizados.
Al crear una página, debe seleccionar una plantilla, que se utilizará como base para crear la página nueva. La plantilla define la estructura de la página resultante, el contenido inicial y los componentes permitidos.
Hay 3 zonas principales Plantillas editables:
A continuación, cree una nueva plantilla en AEM que coincida con la estructura de las maquetas. Esto ocurre en una instancia local de AEM. Siga los pasos del siguiente vídeo:
Pasos de alto nivel para el siguiente vídeo:
/content/experience-fragments/wknd/us/en/site/header/master
.header
. La variable header
se dirigirá a CSS en el capítulo siguiente./content/experience-fragments/wknd/us/en/site/footer/master
.footer
. La variable footer
se dirigirá a CSS en el capítulo siguiente.main
. La variable main
se dirigirá a CSS en el capítulo siguiente.H4
.H5
.Para ver la plantilla en la consola Plantilla , vaya a http://localhost:4502/libs/wcm/core/content/sites/templates.html/conf/wknd
Habilitar la plantilla Página del artículo .
Edite las propiedades de la plantilla Página del artículo y cargue la siguiente miniatura para identificar rápidamente las páginas creadas mediante la plantilla Página del artículo :
Una práctica habitual al crear contenido global, como un encabezado o pie de página, es utilizar un Fragmento de experiencia. Fragmentos de experiencia, permite a los usuarios combinar varios componentes para crear un único componente que se pueda referenciar. Los fragmentos de experiencias tienen la ventaja de admitir la administración en varios sitios y localización.
El tipo de archivo del proyecto de AEM generó un encabezado y un pie de página. A continuación, actualice los fragmentos de experiencias para que coincidan con las maquetas. Siga los pasos del siguiente vídeo:
Pasos de alto nivel para el siguiente vídeo:
/content/wknd/us/en
la página principal./content/wknd/us/en
la página principal.A continuación, cree una nueva página con la plantilla Página de artículo . Cree el contenido de la página para que coincida con las maquetas del sitio. Siga los pasos del siguiente vídeo:
Pasos de alto nivel para el siguiente vídeo:
/content/wknd/us/en/magazine
.En este punto, la página del artículo está claramente desdiseñada. Sin embargo, la estructura básica está establecida. A continuación, inspeccione la estructura de nodos de la página de artículos para comprender mejor la función de la plantilla, la página y los componentes.
Utilice la herramienta CRXDE-Lite en una instancia de AEM local para ver la estructura de nodos subyacente.
Apertura CRXDE-Lite y utilice la navegación de árbol para desplazarse a /content/wknd/us/en/magazine/guide-la-skateparks
.
Haga clic en el jcr:content
nodo debajo de la-skateparks
y vea las propiedades:
Observe el valor de cq:template
, que señala a /conf/wknd/settings/wcm/templates/article-page
, la plantilla de página de artículo que hemos creado anteriormente.
Observe también el valor de sling:resourceType
, que señala a wknd/components/page
. Este es el componente de página creado por el tipo de archivo del proyecto de AEM y es responsable de procesar la página según la plantilla.
Expanda el jcr:content
nodo inferior /content/wknd/us/en/magazine/guide-la-skateparks/jcr:content
y vea la jerarquía de nodos:
Debe poder asignar de forma flexible cada uno de los nodos a los componentes creados. Compruebe si puede identificar los diferentes contenedores de diseño utilizados al inspeccionar los nodos con el prefijo container
.
A continuación, inspeccione el componente de página en /apps/wknd/components/page
. Visualice las propiedades del componente en el CRXDE Lite:
Tenga en cuenta que solo hay 2 scripts HTL, customfooterlibs.html
y customheaderlibs.html
debajo del componente de página. Entonces, ¿cómo procesa este componente la página?
La variable sling:resourceSuperType
la propiedad apunta a core/wcm/components/page/v2/page
. Esta propiedad permite que el componente de página de WKND herede all de la funcionalidad del componente de página Componente principal . Este es el primer ejemplo de algo llamado Patrón de componentes proxy. Encontrará más información aquí..
Inspect otro componente dentro de los componentes WKND, la variable Breadcrumb
componente ubicado en: /apps/wknd/components/breadcrumb
. Observe que el mismo sling:resourceSuperType
se puede encontrar, pero esta vez señala a core/wcm/components/breadcrumb/v2/breadcrumb
. Este es otro ejemplo del uso del patrón de componentes Proxy para incluir un componente principal. De hecho, todos los componentes de la base de código WKND son proxies de AEM componentes principales (excepto nuestro famoso componente HelloWorld). Se recomienda intentar reutilizar la mayor cantidad posible de funciones de los componentes principales before escribir código personalizado.
A continuación, revise la página del componente principal en /libs/core/wcm/components/page/v2/page
uso de CRXDE Lite:
En AEM 6.5/6.4, los componentes principales se encuentran en /apps/core/wcm/components
. En AEM as a Cloud Service, los componentes principales se encuentran en /libs
y se actualizan automáticamente.
Observe que se incluyen muchas más secuencias de comandos debajo de esta página. La página Componentes principales contiene muchas funciones. Esta funcionalidad se divide en varios scripts para facilitar el mantenimiento y la lectura. Puede rastrear la inclusión de los scripts HTL abriendo el page.html
y buscando data-sly-include
:
<!--/* /libs/core/wcm/components/page/v2/page/page.html */-->
<!DOCTYPE HTML>
<html data-sly-use.page="com.adobe.cq.wcm.core.components.models.Page" lang="${page.language}"
data-sly-use.head="head.html"
data-sly-use.footer="footer.html"
data-sly-use.redirect="redirect.html">
<head data-sly-call="${head.head @ page = page}"></head>
<body class="${page.cssClassNames}"
id="${page.id}"
data-cmp-data-layer-enabled="${page.data ? true : false}">
<script data-sly-test.dataLayerEnabled="${page.data}">
window.adobeDataLayer = window.adobeDataLayer || [];
adobeDataLayer.push({
page: JSON.parse("${page.data.json @ context='scriptString'}"),
event:'cmp:show',
eventInfo: {
path: 'page.${page.id @ context="scriptString"}'
}
});
</script>
<sly data-sly-test.isRedirectPage="${page.redirectTarget && (wcmmode.edit || wcmmode.preview)}"
data-sly-call="${redirect.redirect @ redirectTarget = page.redirectTarget}"></sly>
<sly data-sly-test="${!isRedirectPage}">
<sly data-sly-include="body.skiptomaincontent.html"></sly>
<sly data-sly-include="body.socialmedia_begin.html"></sly>
<sly data-sly-include="body.html"></sly>
<sly data-sly-call="${footer.footer @ page = page}"></sly>
<sly data-sly-include="body.socialmedia_end.html"></sly>
</sly>
</body>
</html>
La otra razón para dividir HTL en varios scripts es permitir que los componentes proxy anulen los scripts individuales para implementar la lógica empresarial personalizada. Los scripts HTL, customfooterlibs.html
y customheaderlibs.html
, se crean con el propósito explícito de anularse mediante la implementación de proyectos.
Puede obtener más información sobre cómo la plantilla editable influye en la renderización de la variable página de contenido leyendo este artículo.
Inspect es el otro componente principal, como la ruta de exploración en /libs/core/wcm/components/breadcrumb/v2/breadcrumb
. Consulte la breadcrumb.html
secuencia de comandos para comprender cómo se genera finalmente el marcado del componente de ruta de exploración.
En muchos casos, especialmente al principio de un proyecto AEM, es importante mantener las configuraciones, como las plantillas y las políticas de contenido relacionadas, para el control de código fuente. Esto garantiza que todos los desarrolladores trabajen con el mismo conjunto de contenido y configuraciones, y puede garantizar una coherencia adicional entre entornos. Una vez que un proyecto alcanza un cierto nivel de madurez, la práctica de administrar plantillas se puede transferir a un grupo especial de usuarios avanzados.
Por ahora, trataremos las plantillas como otras partes de código y sincronizaremos el Plantilla de página de artículo como parte del proyecto. Hasta ahora tenemos push código de nuestro proyecto AEM a una instancia local de AEM. La variable Plantilla de página de artículo se creó directamente en una instancia local de AEM, por lo que necesitamos importar la plantilla en nuestro proyecto AEM. La variable ui.content se incluye en el proyecto AEM para este fin específico.
Los siguientes pasos se llevarán a cabo utilizando el IDE de VSCode utilizando la variable VSCode AEM Sync pero podría estar utilizando cualquier IDE que haya configurado para importar o importar contenido desde una instancia local de AEM.
En el VSCode, abra el aem-guides-wknd
proyecto.
Expanda el ui.content en el explorador de proyectos. Expanda el src
carpeta y vaya a /conf/wknd/settings/wcm/templates
.
Clic con el botón derecho el templates
carpeta y seleccione Importar desde AEM servidor:
La variable article-page
debe importarse, y page-content
, xf-web-variation
las plantillas también deben actualizarse.
Repita los pasos para importar contenido, pero seleccione la opción políticas carpeta ubicada en /conf/wknd/settings/wcm/policies
.
Inspect la variable filter.xml
archivo ubicado en ui.content/src/main/content/META-INF/vault/filter.xml
.
<!--ui.content filter.xml-->
<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
<filter root="/conf/wknd" mode="merge"/>
<filter root="/content/wknd" mode="merge"/>
<filter root="/content/dam/wknd" mode="merge"/>
<filter root="/content/experience-fragments/wknd" mode="merge"/>
</workspaceFilter>
La variable filter.xml
es responsable de identificar las rutas de los nodos que se instalarán con el paquete. Observe que mode="merge"
en cada uno de los filtros que indica que el contenido existente no se modificará, solo se añadirá contenido nuevo. Dado que los autores de contenido pueden estar actualizando estas rutas, es importante que una implementación de código not sobrescribir contenido. Consulte la Documentación de FileVault para obtener más información sobre cómo trabajar con elementos de filtro.
Comparar ui.content/src/main/content/META-INF/vault/filter.xml
y ui.apps/src/main/content/META-INF/vault/filter.xml
para comprender los diferentes nodos administrados por cada módulo.
Para garantizar implementaciones coherentes para el sitio de referencia de WKND, algunas ramas del proyecto están configuradas de modo que ui.content
sobrescribirá cualquier cambio en el JCR. Esto es por diseño, es decir, para las ramas de soluciones, ya que el código o los estilos se escribirán para políticas específicas.
Felicidades, acaba de crear una nueva plantilla y página con Adobe Experience Manager Sites.
En este punto, la página del artículo está claramente desdiseñada. Siga las Bibliotecas del lado del cliente y flujo de trabajo del front-end tutorial para conocer las prácticas recomendadas para incluir CSS y Javascript para aplicar estilos globales al sitio e integrar una versión de front-end dedicada.
Ver el código terminado en GitHub o revisar e implementar el código localmente en la rama Git tutorial/pages-templates-solution
.
tutorial/pages-templates-solution
rama.