Componentes de Adobe Experience Manager AEM (): conceptos básicos aem-components-the-basics

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Temas:
Desarrollo

Creado para:

Desarrollador

Cuando empiece a desarrollar nuevos componentes, debe comprender los conceptos básicos de su estructura y configuración.

AEM Este proceso implica leer la teoría y observar la amplia gama de implementaciones de componentes en una instancia de estándar. AEM Este último enfoque se complica ligeramente por el hecho de que, aunque ha cambiado a una nueva IU estándar, moderna y táctil, sigue admitiendo la IU clásica.

Información general overview

Esta sección abarca conceptos y problemas clave como introducción a los detalles necesarios al desarrollar sus propios componentes.

Planificación planning

Antes de empezar a configurar o codificar el componente, debe preguntar lo siguiente:

¿Qué debe hacer exactamente el nuevo componente?
- Una especificación clara ayuda en todas las etapas de desarrollo, pruebas y transferencia. Los detalles pueden cambiar con el tiempo, pero la especificación se puede actualizar (aunque los cambios también deben documentarse).
¿Necesita crear el componente desde cero o puede heredar los conceptos básicos de un componente existente?
- No hay necesidad de reinventar la rueda.
- AEM Existen varios mecanismos proporcionados por los que le permiten heredar y ampliar detalles de otra definición de componente, como invalidación, superposición y la fusión de recursos de Sling.
¿El componente requiere lógica para seleccionar o manipular el contenido?
- La lógica debe mantenerse separada de la capa de interfaz de usuario. HTL está diseñado para ayudar a garantizar que esto suceda.
¿Necesita el componente formato CSS?
- El formato CSS debe mantenerse separado de las definiciones de componentes. Defina convenciones para asignar un nombre a los elementos del HTML para que pueda modificarlos a través de archivos CSS externos.
¿Qué aspectos de seguridad debo tener en cuenta?
- Consulte Lista de comprobación de seguridad - Prácticas recomendadas de desarrollo para obtener más información.

IU táctil o clásica touch-enabled-vs-classic-ui

Antes de que se inicie una conversación seria sobre el desarrollo de componentes, debe saber qué interfaz de usuario utilizan los autores:

IU táctil
La interfaz de usuario estándar se basa en la experiencia de usuario unificada de Adobe Experience Cloud, que usa las tecnologías subyacentes de Coral UI y Granite UI.
IU clásica
AEM Interfaz de usuario basada en la tecnología ExtJS obsoleta con la versión 6.4 de.

Consulte Interfaz de usuario de Recommendations para clientes para obtener más información.

Los componentes se pueden implementar para admitir la IU táctil, la IU clásica o ambas. Al ver una instancia estándar también verá componentes predeterminados que se diseñaron originalmente para la interfaz de usuario clásica, la interfaz de usuario táctil o ambas.

En esta página se tratan los conceptos básicos de ambos y cómo reconocerlos.

NOTE

El Adobe recomienda utilizar la IU táctil para beneficiarse de la tecnología más reciente. AEM Las herramientas de modernización de pueden facilitar la migración.

Lógica de contenido y marcado de procesamiento content-logic-and-rendering-markup

El Adobe recomienda mantener el código responsable del marcado y el procesamiento separado del código que controla la lógica utilizada para seleccionar el contenido del componente.

Esta filosofía es compatible con HTL, un lenguaje de creación de plantillas que está limitado a propósito para garantizar que se use un lenguaje de programación real para definir la lógica empresarial subyacente. Esta lógica (opcional) se invoca desde HTL con un comando específico. Este mecanismo resalta el código que se llama para una vista determinada y, si es necesario, permite una lógica específica para diferentes vistas del mismo componente.

HTL frente a JSP htl-vs-jsp

HTL es un lenguaje de creación de plantillas para HTML AEM incluido en la versión 6.0 de la aplicación de.

AEM La discusión de si se debe usar HTL o JSP (Java™ Server Pages) al desarrollar sus propios componentes debería ser sencilla, ya que HTL es ahora el lenguaje de script recomendado para la creación de páginas de scripts de.

HTL y JSP se pueden utilizar para desarrollar componentes tanto para la IU clásica como para la táctil. Aunque puede haber una tendencia a suponer que HTL es solo para la IU táctil y JSP para la IU clásica, esta es una idea errónea y más debido al tiempo. AEM La interfaz de usuario táctil y HTL se incorporaron a las herramientas de forma durante aproximadamente el mismo periodo. Dado que HTL es ahora el idioma recomendado, se está utilizando para nuevos componentes, que tienden a ser para la interfaz de usuario táctil.

NOTE

Las excepciones son los campos de formulario base de la interfaz de usuario de Granite (como se utilizan en los cuadros de diálogo). Éstos todavía requieren el uso de JSP.

Desarrollo de sus propios componentes developing-your-own-components

Para crear sus propios componentes para la interfaz de usuario adecuada, consulte (después de leer esta página):

Una forma rápida de empezar es copiar un componente existente y luego realizar los cambios que desee. Para aprender a crear sus propios componentes y agregarlos al sistema de párrafos, consulte:

Desarrollar componentes (centrado en la IU táctil)

Mover componentes a la instancia de Publish moving-components-to-the-publish-instance

AEM Los componentes que procesan el contenido deben implementarse en la misma instancia de que el contenido. Por lo tanto, todos los componentes que se utilizan para crear y procesar páginas en la instancia de autor deben implementarse en la instancia de publicación. Cuando se implementan, los componentes están disponibles para procesar las páginas activadas.

Utilice las siguientes herramientas para mover los componentes a la instancia de publicación:

AEM Use el Administrador de paquetes para agregar los componentes a un paquete y moverlos a otra instancia de.
Use la herramienta Activar replicación de árbol para replicar los componentes.

NOTE

Estos mecanismos también se pueden utilizar para transferir el componente entre otras instancias, por ejemplo, desde el desarrollo a la instancia de prueba.

Componentes que hay que tener en cuenta desde el inicio components-to-be-aware-of-from-the-start

Página:
- AEM tiene el componente page ( cq:Page).
- Se trata de un tipo específico de recurso importante para la administración de contenido.
  - Una página corresponde a una página web que contiene contenido para el sitio web.
Sistemas de párrafos:
- El sistema de párrafos es una parte clave de un sitio web, ya que administra una lista de párrafos. Se utiliza para contener y estructurar los componentes individuales que albergan el contenido real.
- Puede crear, mover, copiar y eliminar párrafos en el sistema de párrafos.
- También puede seleccionar los componentes que desea utilizar en un sistema de párrafos específico.
- Hay varios sistemas de párrafos disponibles dentro de una instancia estándar (por ejemplo, parsys, [responsivegrid](/docs/experience-manager-65/sites-authoring/responsive-layout.md)).

Estructura structure

AEM La estructura de un componente de es potente y flexible, las principales consideraciones son:

Tipo de medio
Definición del componente
Propiedades y nodos secundarios de un componente
Cuadros de diálogo
Cuadros de diálogo de diseño
Disponibilidad de componentes
Componentes y el contenido que crean

Tipo de medio resource-type

Un elemento clave de la estructura es el tipo de recurso.

La estructura de contenido declara intenciones.
El tipo de recurso los implementa.

Se trata de una abstracción que ayuda a garantizar que, incluso cuando la apariencia cambia con el tiempo, la intención se mantiene en el tiempo.

Definición del componente component-definition

Conceptos básicos de componentes component-basics

La definición de un componente se puede desglosar de la siguiente manera:

AEM Los componentes de la se basan en Sling.
AEM Los componentes de la se encuentran (generalmente) en:
- HTL: /libs/wcm/foundation/components
- JSP: /libs/foundation/components
Los componentes específicos del proyecto o sitio se encuentran (generalmente) en:
- /apps/<myApp>/components
AEM Los componentes estándar de la se definen como cq:Component y tienen los elementos clave:
- propiedades jcr:
  
  Una lista de propiedades jcr; estas son variables y algunas pueden ser opcionales a través de la estructura básica de un nodo de componente, sus propiedades y subnodos se definen mediante la definición cq:Component
- Recursos:
  
  Definen elementos estáticos utilizados por el componente.
- Scripts:
Se utilizan para implementar el comportamiento de la instancia resultante del componente.
Nodo raíz:
- <mycomponent> (cq:Component): nodo de jerarquía del componente.
Propiedades vitales:
- jcr:title - Título del componente; por ejemplo, se usa como etiqueta cuando el componente aparece en la lista del explorador de componentes o de la barra de tareas.
- jcr:description: descripción del componente; se puede usar como sugerencia de pasar el ratón en el explorador de componentes o la barra de tareas.
- IU clásica:
  - icon.png - Icono de este componente.
  - thumbnail.png: imagen que se muestra si este componente aparece en la lista del sistema de párrafos.
- IU táctil
  - Consulte la sección Icono de componente en la IU táctil para obtener más información.
Nodos secundarios vitales:
- cq:editConfig (cq:EditConfig): define las propiedades de edición del componente y permite que este aparezca en el explorador de componentes o en el Sidekick.
  
  Nota: Si el componente tiene un cuadro de diálogo, aparecerá automáticamente en el navegador o Sidekick de componentes, aunque cq:editConfig no exista.
- cq:childEditConfig (cq:EditConfig): controla los aspectos de la interfaz de usuario del autor para los componentes secundarios que no definen sus propios cq:editConfig.
- IU táctil:
  - cq:dialog ( nt:unstructured): cuadro de diálogo de este componente. Define la interfaz que permite al usuario configurar el componente o editar contenido.
  - cq:design_dialog ( nt:unstructured) - Edición de diseño para este componente
- IU clásica:
  - dialog ( cq:Dialog): cuadro de diálogo de este componente. Define la interfaz que permite al usuario configurar el componente, editar contenido o ambos.
  - design_dialog ( cq:Dialog): edición de diseño para este componente.

Icono de componente en la IU táctil component-icon-in-touch-ui

El icono o la abreviatura del componente se define mediante las propiedades JCR del componente cuando el desarrollador lo crea. Estas propiedades se evalúan en el siguiente orden y se utiliza la primera propiedad válida encontrada.

cq:icon: propiedad de cadena que señala a un icono estándar en la biblioteca de la interfaz de usuario de Coral que se mostrará en el explorador de componentes
- Utilice el valor del atributo HTML del icono Coral.
abbreviation: propiedad de cadena para personalizar la abreviatura del nombre del componente en el explorador de componentes
- La abreviatura debe estar limitada a dos caracteres.
- Si se proporciona una cadena vacía, se genera la abreviatura a partir de los dos primeros caracteres de la propiedad jcr:title.
  - Por ejemplo, "Im" para "Image"
  - El título localizado se utiliza para crear la abreviatura.
- La abreviatura solo se traduce si el componente tiene una propiedad abbreviation_commentI18n, que luego se utiliza como sugerencia de traducción.
cq:icon.png o cq:icon.svg: icono de este componente, que se muestra en el explorador de componentes
- 20 x 20 píxeles es el tamaño de los iconos de los componentes estándar.
  - Los iconos más grandes se reducen (del lado del cliente).
- El color recomendado es rgb(112, 112, 112) > #707070
- El fondo de los iconos de componentes estándar es transparente.
- Solo se admiten .png y .svg archivos.
- Si se realiza la importación desde el sistema de archivos mediante el complemento Eclipse, los nombres de archivo deben evitarse como _cq_icon.png o _cq_icon.svg, por ejemplo.
- .png tiene precedente sobre .svg si ambos están presentes

Si no se encuentra ninguna de las propiedades anteriores ( cq:icon, abbreviation, cq:icon.png o cq:icon.svg) en el componente:

El sistema busca las mismas propiedades en los supercomponentes siguiendo la propiedad sling:resourceSuperType.
Si no se encuentra nada o una abreviatura vacía en el nivel de supercomponente, el sistema crea la abreviatura a partir de las primeras letras de la propiedad jcr:title del componente actual.

Para cancelar la herencia de los iconos de los supercomponentes, al establecer una propiedad abbreviation vacía en el componente, se vuelve al comportamiento predeterminado.

La Consola de componentes muestra cómo se define el icono de un componente en particular.

Ejemplo de icono de SVG svg-icon-example

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" x="0px" y="0px"
     width="20px" height="20px" viewBox="0 0 20 20" enable-background="new 0 0 20 20" xml:space="preserve">
    <ellipse cx="5" cy="5" rx="3" ry="3" fill="#707070"/>
    <ellipse cx="15" cy="5" rx="4" ry="4" fill="#707070"/>
    <ellipse cx="5" cy="15" rx="5" ry="5" fill="#707070"/>
    <ellipse cx="15" cy="15" rx="4" ry="4" fill="#707070"/>
</svg>

Propiedades y nodos secundarios de un componente properties-and-child-nodes-of-a-component

Muchos de los nodos o propiedades necesarios para definir un componente son comunes a ambas IU, y las diferencias permanecen independientes para que el componente pueda trabajar en ambos entornos.

Un componente es un nodo de tipo cq:Component y tiene las siguientes propiedades y nodos secundarios:

Nombre

Tipo

Descripción

cq:Component

Componente actual. Un componente es del tipo de nodo cq:Component.

componentGroup

String

Grupo en el que se puede seleccionar el componente en el navegador de componentes (IU táctil) o en el Sidekick (IU clásica).
Se utiliza un valor de .hidden para componentes que no están disponibles para su selección en la interfaz de usuario, como los sistemas de párrafos reales.

cq:isContainer

Boolean

Indica si el componente es un componente contenedor y, por lo tanto, puede contener otros componentes, como un sistema de párrafos.

cq:dialog

nt:unstructured

Definición del cuadro de diálogo de edición para la IU táctil.

dialog

cq:Dialog

Definición del cuadro de diálogo de edición para la IU clásica.

cq:design_dialog

nt:unstructured

Definición del cuadro de diálogo de diseño para la IU táctil.

design_dialog

cq:Dialog

Definición del cuadro de diálogo de diseño para la IU clásica.

dialogPath

String

Ruta de acceso a un cuadro de diálogo para cubrir el caso cuando el componente no tiene un nodo de diálogo.

cq:cellName

String

Si se establece, esta propiedad se toma como ID de celda. Para obtener más información, consulte el artículo de Knowledge Base Cómo se crean los ID de celda de diseño.

cq:childEditConfig

cq:EditConfig

Cuando el componente es un contenedor (por ejemplo, un sistema de párrafos), controla la configuración de edición de los nodos secundarios.

cq:editConfig

cq:EditConfig

Editar la configuración del componente.

cq:htmlTag

nt:unstructured

Devuelve atributos de etiqueta adicionales que se añaden a la etiqueta HTML adyacente. Permite añadir atributos a los divs generados automáticamente.

cq:noDecoration

Boolean

Si el valor es True, el componente no se representa con las clases div y css generadas automáticamente.

cq:template

nt:unstructured

Si se encuentra, este nodo se utiliza como plantilla de contenido cuando se agrega el componente desde el Explorador de componentes o el Sidekick.

cq:templatePath

String

Ruta a un nodo que se utilizará como plantilla de contenido cuando se añada el componente desde el explorador de componentes o el Sidekick. Debe ser una ruta absoluta, no relativa al nodo de componente.
A menos que desee reutilizar contenido que ya está disponible en otra parte, esto no es obligatorio y cq:template es suficiente (ver a continuación).

jcr:created

Date

Fecha de creación del componente.

jcr:description

String

Descripción del componente.

jcr:title

String

Título del componente.

sling:resourceSuperType

String

Cuando se establece, el componente se hereda de este componente.

virtual

sling:Folder

Permite la creación de componentes virtuales. Para ver un ejemplo, observe el componente de contacto en:
/libs/foundation/components/profile/form/contact

<breadcrumb.jsp>

nt:file

Archivo de script.

icon.png

nt:file

Icono del componente, aparece junto al Título en el Sidekick.

thumbnail.png

nt:file

Miniatura opcional que se muestra al arrastrar el componente a su lugar desde el Sidekick.

Si observa el componente Text (cualquiera de las versiones), podrá ver estos elementos:

HTL ( /libs/wcm/foundation/components/text)
JSP (/libs/foundation/components/text)

Las propiedades de interés particular incluyen:

jcr:title: título del componente; se puede usar para identificar el componente; por ejemplo, aparece en la lista de componentes del explorador de componentes o de la barra de tareas
jcr:description: descripción del componente; se puede usar como sugerencia de pasar el ratón en la lista de componentes de la barra de tareas
sling:resourceSuperType: esto indica la ruta de acceso de la herencia al ampliar un componente (anulando una definición)

Los nodos secundarios de interés particular incluyen:

cq:editConfig ( cq:EditConfig): controla los aspectos visuales; por ejemplo, puede definir el aspecto de una barra o widget, o puede agregar controles personalizados
cq:childEditConfig ( cq:EditConfig): controla los aspectos visuales de los componentes secundarios que no tienen sus propias definiciones
IU táctil:
- cq:dialog ( nt:unstructured): define el cuadro de diálogo para editar el contenido de este componente
- cq:design_dialog ( nt:unstructured): especifica las opciones de edición de diseño para este componente
IU clásica:
- dialog ( cq:Dialog): define el cuadro de diálogo para editar el contenido de este componente (específico de la IU clásica)
- design_dialog ( cq:Dialog): especifica las opciones de edición de diseño para este componente
- icon.png: archivo de gráficos que se utilizará como icono para el componente en el Sidekick
- thumbnail.png: archivo de gráficos que se utilizará como miniatura para el componente mientras lo arrastra desde el Sidekick

Cuadros de diálogo dialogs

Los cuadros de diálogo son un elemento clave del componente, ya que proporcionan una interfaz para que los autores configuren y proporcionen entradas para ese componente.

Según la complejidad del componente, el cuadro de diálogo puede necesitar una o más pestañas para mantener el cuadro de diálogo corto y ordenar los campos de entrada.

Las definiciones de los cuadros de diálogo son específicas de la IU:

NOTE

Por motivos de compatibilidad, la IU táctil puede utilizar la definición de un cuadro de diálogo de IU clásico cuando no se ha definido ningún cuadro de diálogo para la IU táctil.
AEM También se proporcionan Herramientas de modernización de la para ayudarle a ampliar o convertir componentes que solo tienen cuadros de diálogo definidos para la IU clásica.

IU táctil.
- cq:dialog (nt:unstructured) nodos:
  - definir el cuadro de diálogo para editar el contenido de este componente
  - específico para la IU táctil
  - se definen mediante los componentes de la interfaz de usuario de Granite
  - tienen una propiedad sling:resourceType, como estructura de contenido estándar de Sling
  - puede tener una propiedad helpPath para definir el recurso de ayuda contextual (ruta de acceso absoluta o relativa) al que se tiene acceso cuando se selecciona el icono Ayuda (icono ?).
    - Para los componentes listos para usar, a menudo hace referencia a una página de la documentación.
    - Si no se especifica ningún helpPath, se mostrará la dirección URL predeterminada (página de información general de documentación).
En el cuadro de diálogo, se definen campos individuales:
IU clásica
- dialog (cq:Dialog) nodos
  - definir el cuadro de diálogo para editar el contenido de este componente
  - específico para la IU clásica
  - se definen mediante widgets de ExtJS
  - tiene una propiedad xtype, que hace referencia a ExtJS
  - puede tener una propiedad helpPath para definir el recurso de ayuda contextual (ruta absoluta o relativa) al que se tiene acceso cuando se selecciona el botón Ayuda.
    - Para los componentes listos para usar, a menudo hace referencia a una página de la documentación.
    - Si no se especifica ningún helpPath, se mostrará la dirección URL predeterminada (página de información general de documentación).
En el cuadro de diálogo, se definen campos individuales:

En un cuadro de diálogo clásico:
- puede crear el cuadro de diálogo como cq:Dialog, que proporcionará una sola ficha, como en el componente texto, o si necesita varias fichas, como en el componente textimage, el cuadro de diálogo se puede definir como cq:TabPanel.
- se usa un cq:WidgetCollection ( items) para proporcionar una base para campos de entrada ( cq:Widget) o fichas adicionales ( cq:Widget). Esta jerarquía se puede ampliar.

Cuadros de diálogo de diseño design-dialogs

Los cuadros de diálogo de diseño son similares a los cuadros de diálogo utilizados para editar y configurar contenido, pero proporcionan la interfaz para que los autores configuren y proporcionen detalles de diseño para ese componente.

Los cuadros de diálogo de Diseño están disponibles en el modo de diseño, aunque no son necesarios para todos los componentes; por ejemplo, Título y Imagen tienen cuadros de diálogo de diseño, mientras que Texto no.

El cuadro de diálogo de diseño para el sistema de párrafos (por ejemplo, parsys) es un caso especial, ya que permite al usuario seleccionar otros componentes específicos (desde el explorador de componentes o la barra de tareas) en la página.

Adición del componente al sistema de párrafos adding-your-component-to-the-paragraph-system

Una vez definido un componente, debe estar disponible para su uso. Para que un componente esté disponible para su uso en un sistema de párrafos, puede:

Abra Modo de diseño para una página y habilite el componente requerido.
Agregue los componentes necesarios a la propiedad components de su definición de plantilla en:

/etc/designs/<*yourProject*>/jcr:content/<*yourTemplate*>/par

Por ejemplo, consulte:

/etc/designs/geometrixx/jcr:content/contentpage/par

Componentes y el contenido que crean components-and-the-content-they-create

Si crea y configura una instancia del componente Title en la página: <content-path>/Prototype.html

IU táctil.
IU clásica

A continuación, puede ver la estructura del contenido creado dentro del repositorio:

screen_shot_2012-02-13at61405pm

En particular, si observa el texto real de un Título:

la definición (para ambas IU) tiene la propiedad name= ./jcr:title
- /libs/foundation/components/title/cq:dialog/content/items/column/items/title
- /libs/foundation/components/title/dialog/items/title
dentro del contenido, esto genera la propiedad jcr:title que contiene el contenido del autor.

Las propiedades definidas dependen de las definiciones individuales. Aunque pueden ser más complejos que los anteriores, siguen los mismos principios básicos.

Jerarquía y herencia de componentes component-hierarchy-and-inheritance

AEM Los componentes dentro de los segmentos de la lista están sujetos a tres jerarquías diferentes:

Jerarquía de tipos de recursos

Se usa para ampliar componentes con la propiedad sling:resourceSuperType. Esto permite que el componente herede. Por ejemplo, un componente de texto hereda varios atributos del componente estándar.
- scripts (resueltos por Sling)
- diálogos
- descripciones (incluidas imágenes en miniatura e iconos)
Jerarquía de contenedores

Se utiliza para rellenar los ajustes de configuración en el componente secundario y se utiliza principalmente en un escenario de parsys.

Por ejemplo, los ajustes de configuración para los botones de la barra de edición, el diseño del conjunto de controles (barras de edición, rollover) y el diseño del cuadro de diálogo (en línea, flotante) se pueden definir en el componente principal y propagarse a los componentes secundarios.

Las opciones de configuración (relacionadas con la funcionalidad de edición) de cq:editConfig y cq:childEditConfig se propagan.
Incluir jerarquía

Esto se impone en tiempo de ejecución mediante la secuencia de inclusiones.

Esta jerarquía la utiliza Designer, que a su vez actúa como base para varios aspectos de diseño del procesamiento; incluida la información de diseño, la información de CSS y los componentes disponibles en un parsys, entre otros.

Editar comportamiento edit-behavior

En esta sección se explica cómo configurar el comportamiento de edición de un componente. Esto incluye atributos como las acciones disponibles para el componente, las características del editor local y los oyentes relacionados con los eventos del componente.

La configuración es común tanto a la IU táctil como a la clásica, aunque con ciertas diferencias específicas.

El comportamiento de edición de un componente se configura agregando un nodo cq:editConfig de tipo cq:EditConfig debajo del nodo de componente (de tipo cq:Component) y agregando propiedades específicas y nodos secundarios. Están disponibles las siguientes propiedades y nodos secundarios:

cq:editConfig propiedades de nodo:
- cq:actions ( String array): define las acciones que se pueden realizar en el componente.
- cq:layout ( String): define cómo se edita el componente en la IU clásica.
- cq:dialogMode ( String): define cómo se abre el cuadro de diálogo del componente en la IU clásica
  - En la IU táctil, los cuadros de diálogo siempre flotan en el modo escritorio y se abren automáticamente como pantalla completa en dispositivos móviles.
- cq:emptyText ( String): define el texto que se muestra cuando no hay contenido visual.
- cq:inherit ( Boolean): define si los valores que faltan se heredan del componente del que se hereda.
- dialogLayout (String): define cómo se debe abrir el cuadro de diálogo.
cq:editConfig nodos secundarios:
- cq:dropTargets (tipo de nodo nt:unstructured): define una lista de destinos de colocación que pueden aceptar una colocación desde un recurso del buscador de contenido
  - Solo hay varios destinos de colocación disponibles en la IU clásica.
  - En la IU táctil, se permite un solo destino de colocación.
- cq:actionConfigs (tipo de nodo nt:unstructured): define una lista de nuevas acciones que se anexan a la lista cq:actions.
- cq:formParameters (tipo de nodo nt:unstructured): define parámetros adicionales que se agregan al formulario de diálogo.
- cq:inplaceEditing (tipo de nodo cq:InplaceEditingConfig): define una configuración de edición local para el componente.
- cq:listeners (tipo de nodo cq:EditListenersConfig): define lo que sucede antes o después de que se produzca una acción en el componente.

NOTE

En esta página, un nodo (propiedades y nodos secundarios) se representa como XML, como se muestra en el siguiente ejemplo.

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:dialogMode="floating"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
    <cq:listeners
        jcr:primaryType="cq:EditListenersConfig"
        afteredit="REFRESH_PAGE"/>
</jcr:root>

Hay muchas configuraciones existentes en el repositorio. Puede buscar fácilmente propiedades específicas o nodos secundarios:

Para buscar una propiedad del nodo cq:editConfig, por ejemplo, cq:actions, puede usar la herramienta Consulta en CRXDE Lite y buscar con la siguiente cadena de consulta XPath:

//element(cq:editConfig, cq:EditConfig)[@cq:actions]
Para buscar un nodo secundario de cq:editConfig, por ejemplo, puede buscar cq:dropTargets, que es del tipo cq:DropTargetConfig; puede usar la herramienta Query en  CRXDE Lite  y buscar con la siguiente cadena de consulta XPath:

//element(cq:dropTargets, cq:DropTargetConfig)

Marcadores de posición de componentes component-placeholders

Los componentes siempre deben procesar algún HTML visible para el autor, incluso cuando el componente no tenga contenido. De lo contrario, podría desaparecer visualmente de la interfaz del editor, lo que lo haría técnicamente presente, pero invisible en la página y en el editor. En tal caso, los autores no pueden seleccionar e interactuar con el componente vacío.

Por este motivo, los componentes deben representar un marcador de posición siempre que no representen ningún resultado visible cuando la página se procese en el editor de páginas (cuando el modo WCM sea edit o preview).
El marcado de HTML típico para un marcador de posición es el siguiente:

<div class="cq-placeholder" data-emptytext="Component Name"></div>

La secuencia de comandos HTL típica que procesa el HTML de marcador de posición anterior es la siguiente:

<div class="cq-placeholder" data-emptytext="${component.properties.jcr:title}"
     data-sly-test="${(wcmmode.edit || wcmmode.preview) && isEmpty}"></div>

En el ejemplo anterior, isEmpty es una variable que es verdadera solamente cuando el componente no tiene contenido y es invisible para el autor.

Para evitar la repetición, Adobe recomienda que los implementadores de componentes utilicen una plantilla HTL para estos marcadores de posición, como la proporcionada por los componentes principales.

El uso de la plantilla en el vínculo anterior se realiza con la siguiente línea de HTL:

<sly data-sly-use.template="core/wcm/components/commons/v1/templates.html"
     data-sly-call="${template.placeholder @ isEmpty=!model.text}"></sly>

En el ejemplo anterior, model.text es la variable que es verdadera solamente cuando el contenido tiene contenido y es visible.

Se puede ver un ejemplo de uso de esta plantilla en los componentes principales , como en el componente Título.

Configuración con las propiedades cq:EditConfig configuring-with-cq-editconfig-properties

cq:acciones cq-actions

La propiedad cq:actions ( String array) define una o varias acciones que se pueden realizar en el componente. Los siguientes valores están disponibles para la configuración:

Valor de propiedad

Descripción

text:<some text>

Muestra el valor de texto estático <algo de texto>
Solo visible en la IU clásica. La IU táctil no muestra acciones en un menú contextual, por lo que esto no es aplicable.

Agrega un espaciador.
solo visible en la IU clásica. La IU táctil no muestra acciones en un menú contextual, por lo que esto no es aplicable.

edit

Agrega un botón para editar el componente.

editannotate

Agrega un botón para editar el componente y permitir anotaciones.

delete

Agrega un botón para eliminar el componente.

insert

Agrega un botón para insertar un nuevo componente antes del actual.

copymove

Agrega un botón para copiar y cortar el componente.

La siguiente configuración agrega un botón de edición, un espaciador, una eliminación y un botón de inserción a la barra de edición de componentes:

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit,-,delete,insert]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig"/>

La siguiente configuración agrega el texto "Configuraciones heredadas del marco base" a la barra de edición de componentes:

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[text:Inherited Configurations from Base Framework]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig"/>

cq:layout (solo IU clásica) cq-layout-classic-ui-only

La propiedad cq:layout ( String) define cómo se puede editar el componente en la interfaz de usuario clásica. Los valores disponibles son los siguientes:

Valor de propiedad

Descripción

rollover

Valor predeterminado. Se puede acceder a la edición de componentes "al pasar el ratón por encima" mediante clics o menús contextuales.
Para uso avanzado, el objeto correspondiente del lado del cliente es: CQ.wcm.EditRollover.

editbar

Se puede acceder a la edición por componentes mediante una barra de herramientas.
Para uso avanzado, el objeto correspondiente del lado del cliente es: CQ.wcm.EditBar.

auto

La opción se deja en el código del lado del cliente.

NOTE

Los conceptos de rollover y de barra de edición no son aplicables en la IU táctil.

La siguiente configuración agrega un botón de edición a la barra de edición de componentes:

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
</jcr:root>

cq:dialogMode (solo para la IU clásica) cq-dialogmode-classic-ui-only

El componente se puede vincular a un cuadro de diálogo de edición. La propiedad cq:dialogMode ( String) define cómo se abre el cuadro de diálogo del componente en la IU clásica. Los valores disponibles son los siguientes:

Valor de propiedad

Descripción

floating

El cuadro de diálogo es flotante.

inline

(valor predeterminado). El cuadro de diálogo está anclado sobre el componente.

auto

Si la anchura del componente es menor que el valor CQ.themes.wcm.EditBase.INLINE_MINIMUM_WIDTH del lado del cliente, el cuadro de diálogo es flotante; de lo contrario, está en línea.

NOTE

En la IU táctil, los cuadros de diálogo siempre flotan en el modo escritorio y se abren automáticamente como pantalla completa en dispositivos móviles.

La siguiente configuración define una barra de edición con un botón de edición y un cuadro de diálogo flotante:

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:dialogMode="floating"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
</jcr:root>

cq:emptyText cq-emptytext

La propiedad cq:emptyText ( String) define el texto que se muestra cuando no hay contenido visual. El valor predeterminado es: Drag components or assets here.

cq:inherit cq-inherit

La propiedad cq:inherit ( boolean) define si los valores que faltan se heredan del componente del que se hereda. El valor predeterminado es false.

dialogLayout dialoglayout

La propiedad dialogLayout define cómo se debe abrir un cuadro de diálogo de forma predeterminada.

Un valor de fullscreen abre el cuadro de diálogo en pantalla completa.
Un valor vacío o la ausencia de la propiedad toma el valor predeterminado de abrir el cuadro de diálogo normalmente.
El usuario siempre puede alternar el modo de pantalla completa dentro del cuadro de diálogo.
No se aplica a la IU clásica.

Configurar con nodos secundarios cq:EditConfig configuring-with-cq-editconfig-child-nodes

cq:dropTargets cq-droptargets

El nodo cq:dropTargets (tipo de nodo nt:unstructured) define una lista de destinos de colocación que pueden aceptar una colocación de un recurso arrastrado desde el buscador de contenido. Sirve como una colección de nodos de tipo cq:DropTargetConfig.

NOTE

Solo hay varios destinos de colocación disponibles en la IU clásica.

En la IU táctil, solo se utiliza el primer destino.

Cada nodo secundario de tipo cq:DropTargetConfig define un destino de colocación en el componente. El nombre del nodo es importante porque debe utilizarse en JSP de la siguiente manera para generar el nombre de clase CSS asignado al elemento DOM que es el destino de colocación efectivo:

<drop target css class> = <drag and drop prefix> +
 <node name of the drop target in the edit configuration>

La propiedad Java™ define <drag and drop prefix>:

com.day.cq.wcm.api.components.DropTarget.CSS_CLASS_PREFIX.

Por ejemplo, el nombre de clase se define de la siguiente manera en el JSP del componente Descargar
( /libs/foundation/components/download/download.jsp), donde file es el nombre de nodo del destino de colocación en la configuración de edición del componente Descarga:

String ddClassName = DropTarget.CSS_CLASS_PREFIX + "file";

El nodo de tipo cq:DropTargetConfig debe tener las siguientes propiedades:

Nombre de la propiedad

Valor de propiedad

accept

Regex aplicada al tipo MIME del recurso para validar si se permite la colocación.

groups

Matriz de grupos de destino de colocación. Cada grupo debe coincidir con el tipo de grupo definido en la extensión del buscador de contenido y que se adjunta a los recursos.

propertyName

Nombre de la propiedad que se actualizará después de una colocación válida.

La siguiente configuración se toma del componente Descargar. Permite que cualquier recurso (el tipo MIME puede ser cualquier cadena) del grupo media se suelte del buscador de contenido en el componente. Después de la colocación, se actualiza la propiedad de componente fileReference:

    <cq:dropTargets jcr:primaryType="nt:unstructured">
        <file
            jcr:primaryType="cq:DropTargetConfig"
            accept="[.*]"
            groups="[media]"
            propertyName="./fileReference"/>
    </cq:dropTargets>

cq:actionConfigs (solo para la IU clásica) cq-actionconfigs-classic-ui-only

El nodo cq:actionConfigs (tipo de nodo nt:unstructured) define una lista de nuevas acciones que se anexan a la lista definida por la propiedad cq:actions. Cada nodo secundario de cq:actionConfigs define una nueva acción mediante la definición de un widget.

La siguiente configuración de ejemplo define un nuevo botón (con un separador para la IU clásica):

un separador, definido por xtype tbseparator;
- Esto solo se utiliza en la IU clásica.
- La IU táctil ignora esta definición, ya que se ignoran los xtype (y los separadores son innecesarios, ya que la barra de herramientas de acciones se construye de forma diferente en la IU táctil).
un botón denominado Administrar comentarios que ejecuta la función de controlador CQ_collab_forum_openCollabAdmin().

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0"
    cq:actions="[EDIT,COPYMOVE,DELETE,INSERT]"
    jcr:primaryType="cq:EditConfig">
    <cq:actionConfigs jcr:primaryType="nt:unstructured">
        <separator0
            jcr:primaryType="nt:unstructured"
            xtype="tbseparator"/>
        <manage
            jcr:primaryType="nt:unstructured"
            handler="function(){CQ_collab_forum_openCollabAdmin();}"
            text="Manage comments"/>
    </cq:actionConfigs>
</jcr:root>

NOTE

Vea Agregar nueva acción a una barra de herramientas de componentes como ejemplo para la interfaz de usuario táctil.

cq:formParameters cq-formparameters

El nodo cq:formParameters (tipo de nodo nt:unstructured) define parámetros adicionales que se agregan al formulario de diálogo. Cada propiedad se asigna a un parámetro de formulario.

La siguiente configuración agrega un parámetro denominado name, establecido con el valor photos/primary al formulario de diálogo:

    <cq:formParameters
        jcr:primaryType="nt:unstructured"
        name="photos/primary"/>

cq:inplaceEditing cq-inplaceediting

El nodo cq:inplaceEditing (tipo de nodo cq:InplaceEditingConfig) define una configuración de edición local para el componente. Puede tener las siguientes propiedades:

Nombre de la propiedad

Valor de propiedad

active

(boolean) True para habilitar la edición local del componente.

configPath

(String) Ruta de acceso de la configuración del editor. La configuración se puede especificar mediante un nodo de configuración.

editorType

(String) Tipo de editor. Los tipos disponibles son:

texto sin formato: se utilizará para contenido que no sea de HTML.
título: es un editor de texto sin formato mejorado que convierte los títulos gráficos en texto sin formato antes de que comience la edición. Utilizado por el componente de título de Geometrixx.
texto: se utilizará para el contenido del HTML (utiliza el Editor de texto enriquecido).

La siguiente configuración habilita la edición local del componente y define plaintext como el tipo de editor:

    <cq:inplaceEditing
        jcr:primaryType="cq:InplaceEditingConfig"
        active="{Boolean}true"
        editorType="plaintext"/>

cq:listeners cq-listeners

El nodo cq:listeners (tipo de nodo cq:EditListenersConfig) define lo que sucede antes o después de una acción en el componente. La siguiente tabla define sus posibles propiedades.

Nombre de la propiedad

Valor de propiedad

Valor predeterminado

(Solo IU clásica)

beforedelete

El controlador se activa antes de que se quite el componente.

beforeedit

El controlador se activa antes de editar el componente.

beforecopy

El controlador se activa antes de copiar el componente.

beforemove

El controlador se activa antes de mover el componente.

beforeinsert

El controlador se activa antes de insertar el componente.
solo está operativo para la interfaz de usuario táctil.

beforechildinsert

El controlador se activa antes de que el componente se inserte dentro de otro componente (solo contenedores).

afterdelete

El controlador se activa después de eliminar el componente.

REFRESH_SELF

afteredit

El controlador se activa después de editar el componente.

REFRESH_SELF

aftercopy

El controlador se activa después de copiar el componente.

REFRESH_SELF

afterinsert

El controlador se activa después de insertar el componente.

REFRESH_INSERTED

aftermove

El controlador se activa después de mover el componente.

REFRESH_SELFMOVED

afterchildinsert

El controlador se activa después de que el componente se inserte dentro de otro componente (solo contenedores).

NOTE

Los controladores REFRESH_INSERTED y REFRESH_SELFMOVED solo están disponibles en la IU clásica.

NOTE

Los valores predeterminados para los oyentes solo se establecen en la IU clásica.

NOTE

Si hay componentes anidados, existen ciertas restricciones en las acciones definidas como propiedades en el nodo cq:listeners:

Para los componentes anidados, los valores de las siguientes propiedades deben ser REFRESH_PAGE: >
- aftermove
- aftercopy

El controlador de eventos se puede implementar con una implementación personalizada. Por ejemplo, donde project.customerAction es un método estático:

afteredit = "project.customerAction"

El siguiente ejemplo equivale a la configuración de REFRESH_INSERTED:

afterinsert="function(path, definition) { this.refreshCreated(path, definition); }"

NOTE

En la IU clásica, para ver qué parámetros se pueden usar en los controladores, consulte la sección de eventos before<action> y after<action> de la documentación del widget CQ.wcm.EditBar y CQ.wcm.EditRollover.

Con la siguiente configuración, la página se actualiza después de eliminar, editar, insertar o mover el componente:

    <cq:listeners
        jcr:primaryType="cq:EditListenersConfig"
        afterdelete="REFRESH_PAGE"
        afteredit="REFRESH_PAGE"
        afterinsert="REFRESH_PAGE"
        afterMove="REFRESH_PAGE"/>

recommendation-more-help

19ffd973-7af2-44d0-84b5-d547b0dffee2