Tag de decoração decoration-tag

Quando um componente em uma página da Web é renderizado, um elemento HTML pode ser gerado, vinculando o componente renderizado dentro de si mesmo. Isso serve principalmente a dois propósitos:

Para desenvolvedores, o AEM oferece lógica simples e clara controlando as tags de decoração que envolvem componentes incluídos. Se e como a tag de decoração é renderizada é definida pela combinação de dois fatores, nos quais essa página se aprofundará:

Recomendações recommendations

Estas são algumas recomendações gerais de quando incluir o elemento invólucro que devem ajudar a evitar problemas inesperados:

Controles de componente component-controls

As seguintes propriedades e nós podem ser aplicados aos componentes para controlar o comportamento da tag de decoração:

Controles de script script-controls

Em geral, o comportamento do invólucro no HTL pode ser resumido da seguinte maneira:

O comportamento do invólucro também pode ser totalmente controlado.

É possível controlar totalmente o comportamento das tags do invólucro de scripts HTL e sua lógica associada.

Para obter mais informações sobre como desenvolver em HTL, consulte a documentação HTL.

Árvore de decisão decision-tree

Essa árvore decisória resume a lógica que determina o comportamento das tags do invólucro.

Casos de uso use-cases

Os três casos de uso a seguir fornecem exemplos de como as tags do invólucro são tratadas e também ilustram como é simples controlar o comportamento desejado das tags do invólucro.

Todos os exemplos a seguir pressupõem a seguinte estrutura de conteúdo e componentes:

/content/test/
  @resourceType = "test/components/one"
  child/
    @resourceType = "test/components/two"

/apps/test/components/
  one/
    one.html
  two/
    two.html
    cq:htmlTag/
      @cq:tagName = "article"
      @class = "component-two"

Caso de uso 1: Incluir um componente para reutilização de código use-case-include-a-component-for-code-reuse

O caso de uso mais comum é quando um componente inclui outro componente por motivos de reutilização de código. Nesse caso, o componente incluído não é desejado para ser editável com sua própria barra de ferramentas e caixa de diálogo, portanto, nenhum invólucro é necessário e o cq:htmlTag do componente é ignorado. Esse pode ser considerado o comportamento padrão.

one.html: <sly data-sly-resource="child"></sly>

two.html: Hello World!

Saída resultante em /content/test.html:

Hello World!

Um exemplo seria um componente que inclui um componente de imagem principal para exibir uma imagem, normalmente nesse caso usando um recurso sintético, que consiste em incluir um componente filho virtual ao passar para o recurso data-sly um objeto de Mapa que representa todas as propriedades que o componente teria.

Caso de uso 2: incluir um componente editável use-case-include-an-editable-component

Outro caso de uso comum é quando componentes de contêiner incluem componentes filhos editáveis, como um Contêiner de layout. Nesse caso, cada filho incluído precisa imperativamente de um invólucro para que o editor funcione (a menos que explicitamente desabilitado com a propriedade cq:noDecoration ).

Como o componente incluído é, neste caso, um componente independente, ele precisa de um elemento wrapper para que o editor funcione e para definir seu layout e estilo a serem aplicados. Para acionar esse comportamento, há a opção decoration=true.

one.html: <sly data-sly-resource="${'child' @ decoration=true}"></sly>

two.html: Hello World!

Saída resultante em /content/test.html:

<article class="component-two">Hello World!</article>

Caso de uso 3: comportamento personalizado use-case-custom-behavior

Pode haver qualquer número de casos complexos, que podem ser facilmente obtidos com a possibilidade de o HTL fornecer explicitamente:

one.html: <sly data-sly-resource="${'child' @ decorationTagName='aside', cssClassName='child'}"></sly>

two.html: Hello World!

Saída resultante /content/test.html:

<aside class="child">Hello World!</aside>