Migración de IU clásica a táctil para AEM: más sugerencias de Experiencia

(Liubou Masiuk) (17 de octubre de 2019)

En nuestra publicación anterior (publicación sobre la migración de Classic a TouchUI) describimos nuestro enfoque general de «Modo híbrido» para migrar una biblioteca de componentes de UI completamente clásica a Touch UI usando Modo de compatibilidad de AEM. En la publicación, aludimos a algunas «peculiaridades» que encontramos. En esta nueva publicación, entramos en muchos más detalles sobre estas peculiaridades y cómo lidiar con algunas de estas peculiaridades.

Aunque el modo híbrido es extremadamente útil, tiene algunas limitaciones que pueden evitar que el equipo de desarrollo adopte TouchUI sin esfuerzo adicional en proyectos grandes. Estos son algunos de los problemas que encontramos y las soluciones que encontró nuestro equipo de desarrollo.

El autor no puede arrastrar & soltar imágenes mientras edita un componente

La biblioteca de widgets de ClassicUI proporciona un componente SmartImage para cargar y procesar imágenes. Los activos de imagen de forma predeterminada se pueden cargar de dos formas diferentes:

  • Desde el sistema de archivos
  • Desde el DAM (Administrador de activos digitales) arrastrando la imagen desde el buscador de contenido de la página panel en el lado izquierdo
Panel de activos DAM (interfaz TouchUI)
Panel de activos DAM (Interfaz TouchUI)

Profundicemos en los detalles técnicos de la implementación de TouchUI. El modo de compatibilidad muestra un cuadro de diálogo ClassicUI dentro de un iframe. Por alguna razón, el modo compatible no tiene ninguna lógica para rastrear eventos de arrastrar & soltar fuera de la caja. Esto impide que los autores arrastren imágenes fuera del panel Activos (ya que están acostumbrados a hacerlo dentro de la experiencia de ClassicUI). Esto significa que no tienen forma de colocar la imagen en el componente. Además, cuando se requiere un campo de imagen, el autor no tiene la opción de completar la configuración del componente debido a un campo requerido vacío.

Solución

Para resolver este problema, decidimos Extienda el componente Standard SmartImage para representar un campo de ruta además de la funcionalidad existente. Como resultado, el autor tiene la capacidad de seleccionar una imagen mediante el campo de ruta y la imagen aparece dentro del área de SmartImage para obtener una vista previa y / o cambiar la imagen si es necesario. Para las rutas que no existen (o rutas que no son de imagen), el campo se resalta como no válido.

Área de imagen requerida dentro del componente
Área de imagen requerida dentro del componente
  1. Vuelva a registrar el xtype htmlsamartimage original con uno personalizado inherente que amplíe el original Widget de CQ HtmlSmartImage. En la inicialización del nuevo widget, agregamos un widget PathField adicional a los contenedores de componentes. Además, proporcionamos pequeñas actualizaciones para el diseño del widget predeterminado que es una actualización de la interfaz de usuario común para las interfaces de usuario basadas en ExtJS.
  2. Controles de enlace (PathFields) en todas las HTMLSmartImages. En primer lugar, preparamos ayudantes creando métodos para obtener y establecer valores de PathPicker y los mismos métodos para el componente original. El primer par es setValue y getValue de PathField, que es la parte fácil. La parte complicada es lidiar con el valor del componente original. HTMLSmartImage no almacena su valor en un estado accesible.

Para obtener la ruta de la imagen actual se puede hacer fácilmente mediante el método this.fileReferenceField.getValue (). Pero para establecer el valor en el widget original, necesitamos emular un recurso de imagen en el componente. Podemos gestionar eso de la siguiente manera:

Ahora que tenemos todos los descriptores de acceso de valor, necesitamos saber cuándo el valor original y el valor de Pathfield están cambiando. Para rastrear los cambios de Pathfield, podemos usar un evento de «desenfoque». Para el widget original, el evento «imagestate» es el más adecuado. Necesitamos rastrear dos tipos de cambios de estado de la imagen: originalremoved y originalavailable, por lo que el oyente puede ser el siguiente:

Ahora, está listo para vincularse. Para mantener el mecanismo de validación en la nueva implementación, anulamos la lógica de validación original para la instancia del campo de ruta incrustado.

Todos los diálogos de campos de scaffolding están deshabilitados

AEM El modo de andamio permite a un autor crear fácilmente páginas basadas en una estructura de formulario de andamio específica. Los andamios son extremadamente útiles para crear contenido estructurado bien definido (por ejemplo, artículos, publicaciones de blogs).

En el modo híbrido, todos los campos de formulario de andamios están deshabilitados, lo que significa que no se pueden editar.

Ejemplo de formulario de andamio
Ejemplo de formulario de andamio

Solución

La inclusión de la biblioteca cq.security en el JSP de la página resolvió el problema y los formularios de scaffolding comenzaron a funcionar correctamente.

El cuadro de diálogo híbrido se cierra sin guardar datos al hacer clic fuera del área de diálogo

Todos los componentes se editan dentro de la ventana de diálogo de configuración de componentes, que aparece en modo de edición.

Edición de un componente en AEM (interfaz TouchUI)
Edición de un componente en AEM (interfaz TouchUI)

Hay una pequeña diferencia en la experiencia del usuario en los cuadros de diálogo Hybrid y TouchUI:

  • Si un usuario hace clic fuera del cuadro de diálogo TouchUI, no sucede nada.
  • Si un usuario hace clic fuera del cuadro de diálogo híbrido diálogo, se cierra sin guardar los datos ingresados.

Esto significa que todos los datos no guardados son g ¡Que se pierda en caso de un clic accidental fuera del componente! No hace falta decir que esto es bastante molesto para los autores.

Solución

Afortunadamente, la solución es bastante simple. Inicialmente, el fondo de diálogo está en modo «modal». Para cambiar el modo de fondo del diálogo, el archivo JSP del diálogo debe superponerse y el modo de fondo del diálogo debe establecerse en el valor «estático».

Algunos campos de diálogo no se ajustan al área de la ventana de diálogo

Como ya describimos antes, los cuadros de diálogo de la interfaz de usuario se representan en un iframe dentro de la ventana de diálogo de TouchUI. Esta ventana de diálogo a veces no se ajusta a todo el contenido dinámico, lo que a veces provoca un diseño extraño donde aparecen barras de desplazamiento adicionales dentro del diálogo.

Desplazamiento adicional elemento para el componente en modo híbrido
Elemento de desplazamiento adicional para el componente en modo híbrido

Solución

Para superar este inconveniente, superponemos el archivo JSP que contiene todos los ajustes de configuración para representar correctamente los diálogos en el modo de compatibilidad. Este archivo JSP se coloca dentro de lo siguiente en la siguiente ruta:

apps/cq/gui/components/authoring/compat/components/dialog/dialog.jsp

Cambiamos el ancho y alto de la ventana para considerar el original las dimensiones del cuadro de diálogo, así como el tamaño de la ventana del navegador.

Manejamos esta situación a través de un script que en realidad proporciona un enlace entre la envoltura de la interfaz de usuario táctil (Coral) y el cuadro de diálogo clásico incrustado en el iframe. El evento «dialogwrapper-ready» + ns es necesario para eso con ancho y alto precalculados como parámetros de función del controlador. También es posible hacer su propio recálculo y luego establecer el ancho y alto para el contenido del Diálogo Coral:

Algunos componentes no se pueden editar en TouchUI (fácilmente)

La experiencia de creación es uno de los puntos más importantes a considerar al implementar componentes en AEM. Imagine un componente de carrusel que contiene varias diapositivas. En el modo de edición, es mejor representar todas las diapositivas del carrusel como una columna para que el autor pueda reorganizar fácilmente el orden de las diapositivas y acceder a todas ellas simultáneamente sin cambiar entre las diapositivas. Hay una diferencia importante entre ClassicUI y TouchUI:

  • En ClassicUI, los elementos de creación (por ejemplo, las barras de edición) son parte del marcado que se representa con el componente en el modo de edición.
  • En TouchUI, los elementos de creación se representan en una superposición. El marcado del componente final se representa en un iframe. La combinación de estas condiciones lleva al autor a la situación en la que no es posible interactuar con el componente en el modo de edición (por ejemplo, hacer clic en los botones, hojear las diapositivas de un carrusel).

Así que nos enfrentamos a casos en los que un par de componentes de nuestra biblioteca requieren cierta interacción antes de que el usuario pueda iniciar el proceso de edición, pero esto no se puede lograr fácilmente en TouchUI.

Soluciones

Sin embargo, hay un par de correcciones que podrían considerarse como posibles soluciones:

  1. Existe una solución rápida y sencilla que no requiere esfuerzo de desarrollo: todos los componentes editables se pueden encontrar en el Árbol de contenido y hay un icono de llave inglesa junto a cada uno de ellos que abre el cuadro de diálogo de edición.
Árbol de contenido de la página en TouchUI interfaz
Árbol de contenido de la página en la interfaz TouchUI

2. Para componentes complejos con muchos subcomponentes, el marcado del componente en el modo de edición se puede cambiar para hacer que todas las áreas de componentes «ocultas» estén abiertas a los «ojos» del autor. Esto significaría que todo está visible y accesible a través del modo de edición.

3. Como práctica recomendada, Adobe proporciona una solución para admitir un caso de experiencia de creación de este tipo dentro de AEM Core Components . Componente de carrusel y Componente de pestañas utilizan la opción Seleccionar panel en la barra de herramientas del componente para reordenar las diapositivas y visualiza y cambia el elemento de vista previa actualmente.

Solución lista para usar para llegar a contenido oculto a la creación
Solución lista para usar para acceder a contenido oculto a la creación

El botón «desbloquear página» no funciona

Existe una opción estándar de AEM para bloquear y desbloquear la página para cambios. Al validar el enfoque de migración de TouchUI, encontramos una situación en la que el autor no podía revertir una página «bloqueada» a su estado inicial. Afortunadamente, esta funcionalidad funciona correctamente a través de AEM Site Console.

Opción Bloquear en la interfaz TouchUI
Opción de bloqueo en la interfaz TouchUI

Un problema similar se describe aquí y aquí .

Solución

El mensaje de error en la consola del navegador dice que “No se puede leer la propiedad compartida de indefinida ”. La causa principal radica en la falta de una biblioteca cliente cq.shared.

Mensaje de error al tratar con la funcionalidad
Mensaje de error al tratar con la funcionalidad Bloqueo / Desbloqueo

La inclusión de la biblioteca cq.shared en el JSP de la página resuelve el problema y el botón «Desbloquear página» comienza a funcionar como se esperaba.

Autores: Volha Lunkova , Liubou Masiuk, Aliaksei Stsefanovich

Publicado originalmente en https://exadel.com el 17 de octubre de 2019.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *