Desarrollo de SPA para AEM

Las aplicaciones de una sola página (SPA) pueden oferta experiencias atractivas para los usuarios de sitios web. Los desarrolladores quieren poder crear sitios con marcos de SPA y los autores quieren editar contenido dentro de AEM sin problemas para un sitio creado con dichos marcos.

Este artículo presenta importantes cuestiones que deben tenerse en cuenta al contratar a un desarrollador front-end para desarrollar un SPA para AEM y ofrece una visión general de la arquitectura de AEM con respecto a la implementación de SPA en AEM.

NOTE

La función Editor de aplicaciones de una sola página (SPA) requiere AEM 6.4 service pack 2 o posterior.

El Editor de SPA es la solución recomendada para proyectos que requieren procesamiento del cliente basado en el marco de SPA (por ejemplo, React o Angular).

Tipo de archivo del proyecto AEM

Cualquier proyecto AEM debe aprovechar el AEM Arquetipode proyecto, que admite proyectos de SPA con React o Angular y aprovecha el SDK de SPA.

Principios de desarrollo de la ZEPA para la AEM

El desarrollo de aplicaciones de una sola página en AEM supone que el desarrollador front-end observa las optimizaciones estándar al crear un SPA. Si, como desarrollador front-end, sigue estas optimizaciones generales, así como algunos principios específicos de AEM, su SPA funcionará con AEM y sus capacidadesde creación de contenido.

  • Portabilidad-​Como con cualquier componente, los componentes se deben crear para que sean lo más portátiles posible. El SPA debe crearse con componentes transferibles y reutilizables, evitando las rutas estáticas que hacen referencia a la estructura de contenido.
  • AEM impulsa la estructura​del sitio: el desarrollador front-end crea componentes y posee su estructura interna, pero depende de AEM para definir la estructura de contenido del sitio.
  • Procesamientodinámico:​todo el procesamiento debe ser dinámico.
  • Enrutamientodinámico:​el SPA es responsable del enrutamiento y AEM lo escucha y obtiene los datos del componente basados en él. Cualquier enrutamiento también debería ser dinámico.

Si tiene en cuenta estos principios a medida que desarrolla su SPA, será lo más flexible y la prueba más futura posible, al tiempo que se habilitará toda la funcionalidad de creación de AEM admitida.

Si no necesita admitir AEM funciones de creación, puede que tenga que considerar un modelo de diseño deSPA diferente.

Portabilidad

Al igual que al desarrollar cualquier componente, los componentes deben diseñarse de manera que se maximice su portabilidad. Cualquier patrón que funcione en contra de la portabilidad o reutilización de los componentes debe evitarse para garantizar la compatibilidad, la flexibilidad y la sostenibilidad a partir de ahora.

El desarrollador debe evitar utilizar rutas estáticas que hagan referencia a la estructura de contenido, ya que los autores de contenido pueden modificar las rutas en cualquier momento. Esto también restringe la reutilización de la biblioteca y evita que se utilice el Editor de plantillas de AEM, ya que su estructura se encuentra en otra ubicación que el contenido.

El SPA resultante debe construirse con componentes muy portátiles y reutilizables.

AEM impulsa la estructura del sitio

El desarrollador de front-end debe considerarse responsable de crear una biblioteca de componentes de SPA que se utilizan para crear la aplicación. El desarrollador front-end tiene control total de la estructura interna de los componentes. Sin embargo, AEM en todo momento posee la estructura del sitio.

Esto significa que el desarrollador front-end puede añadir contenido de cliente antes o después del punto de entrada de los componentes y también puede realizar llamadas de terceros dentro del componente. Sin embargo, el desarrollador de front-end no tiene el control absoluto de cómo se anidan los componentes, por ejemplo.

Procesamiento dinámico

El SPA solo debe basarse en la representación dinámica del contenido. Es la expectativa predeterminada en la que AEM captura y procesa todos los elementos secundarios de la estructura de contenido.

Cualquier representación explícita que apunte a contenido específico se considera representación estática y aunque se admite, no será compatible con las funciones de creación de contenido de AEM. Esto también va en contra del principio de portabilidad.

Enrutamiento dinámico

Al igual que en el procesamiento, todo el enrutamiento también debe ser dinámico. En AEM, el SPA siempre debe ser propietario del enrutamiento y AEM lo escucha y obtiene contenido basado en él.

Cualquier enrutamiento estático va en contra del principio de portabilidad y limita al autor al no ser compatible con las funciones de creación de contenido de AEM. Por ejemplo, con un enrutamiento estático, si el autor del contenido desea cambiar una ruta o una página, deberá pedir al desarrollador del front-end que lo haga.

Modelos de diseño de SPA

Si se siguen los principios de desarrollo de SPA en AEM , el SPA funcionará con todas las funciones de creación de contenido AEM admitidas.

Sin embargo, puede haber casos en los que esto no es totalmente necesario. La siguiente tabla ofrece una visión general de los distintos modelos de diseño, sus ventajas y sus desventajas.

Modelo de diseño
Ventajas Desventajas
AEM se utiliza como un CMS sin encabezado sin utilizar el marco del SDK del Editor de SPA. El desarrollador front-end tiene control total sobre la aplicación.

Los autores de contenido no pueden aprovechar AEM experiencia de creación de contenido.

El código no es portátil ni reutilizable si contiene referencias estáticas o enrutamiento.

No permite el uso del editor de plantillas, por lo que el desarrollador front-end debe mantener plantillas editables mediante el JCR.

El desarrollador front-end utiliza el marco SDK del Editor de SPA, pero solo abre algunas áreas para el autor del contenido. El desarrollador mantiene el control sobre la aplicación al habilitar únicamente la creación en áreas restringidas de la aplicación.

Los autores de contenido están restringidos a un conjunto limitado de experiencias de creación de contenido AEM.

El código no puede ser portátil ni reutilizable si contiene referencias estáticas o enrutamiento.

No permite el uso del editor de plantillas, por lo que el desarrollador front-end debe mantener plantillas editables mediante el JCR.

El proyecto aprovecha completamente el SDK del Editor de SPA y los componentes principales se desarrollan como una biblioteca y la estructura de contenido de la aplicación se delega en AEM.

La aplicación es reutilizable y portátil.

El autor del contenido puede editar la aplicación con AEM experiencia de creación de contenido.

El SPA es compatible con el editor de plantillas.

El desarrollador no controla la estructura de la aplicación ni la parte del contenido delegada a AEM.

El desarrollador aún puede reservar áreas de la aplicación para el contenido que no está pensado para ser creado con AEM.

NOTE

Aunque todos los modelos se admiten en AEM, solo implementando el tercero (y siguiendo así los principios de desarrollo de SPA recomendados en AEM) los autores de contenido podrán interactuar con el contenido de la SPA y editarlo en AEM tal como están acostumbrados.

Migración de SPA existentes a AEM

Generalmente, si su SPA sigue los Principios de desarrollo de SPA para AEM, su SPA funcionará en AEM y será editable con el Editor de SPA de AEM.

Siga estos pasos para que el SPA existente esté listo para trabajar con AEM.

  1. Haga que los componentes de JS sean modulares.

    Hacerlos capaces de procesarse en cualquier orden, posición y tamaño.

  2. Utilice los contenedores proporcionados por nuestro SDK para colocar sus componentes en la pantalla.

    AEM proporciona un componente de sistema de páginas y párrafos para que pueda utilizarlo.

  3. Cree un componente de AEM para cada componente de JS.

    Los componentes AEM definen el cuadro de diálogo y la salida JSON.

Instrucciones para desarrolladores de front-end

La principal tarea de lograr que un desarrollador front-end cree un SPA para AEM es acordar los componentes y sus modelos JSON.

A continuación se describen los pasos que debe seguir un desarrollador front-end al desarrollar un SPA para AEM.

  1. Aceptar los componentes y su modelo JSON

    Los desarrolladores de front-end y los desarrolladores de AEM de back-end deben acordar qué componentes son necesarios y qué modelo, de modo que exista una coincidencia individual entre los componentes de SPA y los componentes de back-end.

    AEM componentes siguen siendo necesarios principalmente para proporcionar cuadros de diálogo de edición y para exportar el modelo de componentes.

  2. En componentes React, acceda al modelo mediantethis.props.cqModel

    Una vez que se han acordado los componentes y se ha implantado el modelo JSON, el desarrollador front-end puede desarrollar el SPA y simplemente acceder al modelo JSON a través de this.props.cqModel.

  3. Implementar el métodorender()del componente

    El desarrollador de front-end implementa el render() método según lo considere necesario y puede utilizar los campos de la cqModel propiedad. Esto genera los fragmentos DOM y HTML que se insertarán en la página. Esta es la forma estándar de crear una aplicación en React.

  4. Asigne el componente al tipo de recurso AEM medianteMapTo()

    La asignación almacena clases de componente y el componente proporcionado la utiliza internamente para recuperar y crear instancias dinámicas de componentes en función del tipo de recurso determinado. Container

    Esto sirve como "pegamento" entre el front-end y el back-end, de modo que el editor sabe a qué componentes de reacción corresponden.

    Los Page y ResponsiveGrid son buenos ejemplos de clases que extienden la base Container.

  5. Defina el parámetro del componenteEditConfigcomoMapTo()

    Este parámetro es necesario para indicar al editor cómo se debe nombrar el componente mientras no se procese o no tenga contenido para procesar.

  6. Extender laContainerclase proporcionada para páginas y contenedores

    Los sistemas de páginas y párrafos deben ampliar esta clase para que la delegación a los componentes internos funcione según lo previsto.

  7. Implemente una solución de enrutamiento que utilice la API de HTML5History.

    Cuando ModelRouter está activado, la llamada a las funciones pushState y replaceState activará una solicitud al PageModelManager para recuperar un fragmento que falta del modelo.

    La versión actual del modelo ModelRouter solo admite el uso de direcciones URL que apunten a la ruta de recursos real de los puntos de entrada del modelo de Sling. No admite el uso de direcciones URL personales o alias.

    El ModelRouter se puede deshabilitar o configurar para ignorar una lista de expresiones regulares.

AEM-agnóstico

Estos bloques de código ilustran cómo los componentes React y Angular no necesitan nada que sea Adobe o AEM específico.

  • Todo lo que se encuentra dentro del componente JavaScript no es AEM.
  • Sin embargo, lo que es específico de AEM es que el componente JS debe asignarse a un componente AEM con el asistente MapTo.

screen_shot_2018-12-11at144019

El MapTo ayudante es el "pegamento" que permite que los componentes del back-end y del front-end se comparen entre sí:

  • Indica al contenedor JS (o sistema de párrafos JS) qué componente JS es responsable de procesar cada uno de los componentes presentes en el JSON.
  • Agrega un atributo de datos HTML al HTML que representa el componente JS, de modo que el Editor de SPA sepa qué cuadro de diálogo mostrar al autor al editar el componente.

Para obtener más información sobre el uso MapTo y la creación de SPA para AEM en general, consulte la Guía de introducción de su estructura seleccionada.

Arquitectura AEM y SPA

La arquitectura general de AEM, incluidos los entornos de desarrollo, creación y publicación, no cambia al utilizar SPA. Sin embargo, es útil comprender cómo encaja el desarrollo de SPA en esta arquitectura.

screen_shot_2018-12-11at145348

  • Generar Entorno

    Aquí es donde el origen de la aplicación SPA y el origen de componentes están desprotegidos.

    • El generador clientlib de NPM crea una biblioteca de cliente del proyecto SPA.
    • Maven se encargará de la utilización de esa biblioteca y la implementará el complemento Maven Build junto con el componente en AEM Author.
  • AEM Author

    El contenido se crea en el autor AEM, incluidos los SPA de creación.

    Cuando se edita un SPA con el Editor de SPA en el entorno de creación:

    1. El SPA solicita el HTML externo.
    2. Se carga la CSS.
    3. Se carga el Javascript de la aplicación SPA.
    4. Cuando se ejecuta la aplicación SPA, se solicita el JSON, lo que permite a la aplicación crear el DOM de la página, incluidos los cq-data atributos.
    5. Estos cq-data atributos permiten al editor cargar información de página adicional para saber qué configuraciones de edición están disponibles para los componentes.
  • AEM Publish

    Aquí es donde el contenido creado y las bibliotecas compiladas, incluidos los artefactos de la aplicación SPA, clientlibs y componentes, se publican para consumo público.

  • Dispatcher/CDN

    El despachante sirve como capa de almacenamiento en caché de AEM para visitantes al sitio.

    • Las solicitudes se procesan de forma similar a como se encuentran en AEM Author; sin embargo, no hay ninguna solicitud de la información de la página, ya que solo lo necesita el editor.
    • Javascript, CSS, JSON y HTML se almacenan en caché, lo que optimiza la página para un envío rápido.
NOTE

Dentro de AEM no hay necesidad de ejecutar los mecanismos de compilación de Javascript ni de ejecutar el propio Javascript. AEM solo aloja los artefactos compilados de la aplicación SPA.

Próximos pasos

Para obtener una descripción general de cómo se estructura un SPA simple en AEM y cómo funciona, consulte la guía de introducción para React y Angular.

Para obtener una guía paso a paso sobre cómo crear su propio SPA, consulte el tutorial Introducción al Editor de SPA de AEM - Eventos WKND.

Para obtener más información sobre la asignación de modelos dinámicos a componentes y cómo funciona en las SPA de AEM, consulte el artículo Asignación de modelos dinámicos a componentes para SPA.

Si desea implementar SPA en AEM para un marco de trabajo distinto a React o Angular o simplemente desea profundizar en el funcionamiento del SDK de SPA para AEM, consulte el artículo SPA Blueprint .

En esta página