Modelagem de conteúdo para criação WYSIWYG com projetos Edge Delivery Services content-modeling

Saiba como a modelagem de conteúdo funciona para a criação WYSIWYG com projetos Edge Delivery Services e como modelar seu próprio conteúdo.

Pré-requisitos prerequisites

Projetos que usam a criação WYSIWYG com Edge Delivery Services herdam a maioria dos mecanismos de qualquer outro projeto Edge Delivery Services, independentemente da fonte de conteúdo ou do método de criação.

Antes de começar a modelar o conteúdo para seu projeto, primeiro leia a documentação a seguir.

É essencial compreender esses conceitos para criar um modelo de conteúdo atraente que funcione de forma independente da origem do conteúdo. Este documento fornece detalhes sobre os mecanismos implementados especificamente para a criação WYSIWYG.

Conteúdo padrão default-content

O conteúdo padrão é o conteúdo que um autor intuitivamente colocaria em uma página sem adicionar nenhuma semântica adicional. Isso inclui texto, cabeçalhos, links e imagens. Esse conteúdo é autoexplicativo em sua função e propósito.

No AEM, esse conteúdo é implementado como componentes com modelos muito simples e predefinidos, que incluem tudo o que pode ser serializado no Markdown e no HTML.

O modelo desses componentes faz parte da Estrutura para criação WYSIWYG com Edge Delivery Services.

Blocos blocks

Os blocos são usados para criar conteúdo mais rico com estilos e funcionalidades específicas. Ao contrário do conteúdo padrão, os blocos exigem semântica adicional. Os blocos podem ser comparados a componentes no editor de páginas AEM.

Os blocos são essencialmente pedaços de conteúdo decorados pelo JavaScript e estilizados com uma folha de estilos.

Definição do modelo de bloco model-definition

Ao usar a criação WYSIWYG com Edge Delivery Services, o conteúdo dos blocos deve ser modelado explicitamente para fornecer ao autor a interface para criar conteúdo. Basicamente, é necessário criar um modelo para que a interface do usuário de criação saiba quais opções apresentar ao autor com base no bloco.

O arquivo component-models.json define o modelo de blocos. Os campos definidos no modelo de componente são mantidos como propriedades no AEM e renderizados como células na tabela que compõe um bloco.

{
  "id": "hero",
  "fields": [
    {
      "component": "reference",
      "valueType": "string",
      "name": "image",
      "label": "Image",
      "multi": false
    },
    {
      "component": "text-input",
      "valueType": "string",
      "name": "imageAlt",
      "label": "Alt",
      "value": ""
    },
    {
      "component": "text-area",
      "name": "text",
      "value": "",
      "label": "Text",
      "valueType": "string"
    }
  ]
}

Observe que nem todos os blocos devem ter um modelo. Alguns blocos são simplesmente containers para uma lista de filhos, onde cada filho tem seu próprio modelo.

Também é necessário definir quais blocos existem e quais podem ser adicionados a uma página usando o Editor universal. O arquivo component-definitions.json lista os componentes à medida que eles são disponibilizados pelo Editor Universal.

{
  "title": "Hero",
  "id": "hero",
  "plugins": {
    "xwalk": {
      "page": {
        "resourceType": "core/franklin/components/block/v1/block",
        "template": {
          "name": "Hero",
          "model": "hero"
        }
      }
    }
  }
}

É possível usar um modelo para muitos blocos. Por exemplo, alguns blocos podem compartilhar um modelo que define um texto e uma imagem.

Para cada bloco, o desenvolvedor:

Todas essas informações são armazenadas no AEM quando um bloco é adicionado a uma página. Se o tipo de recurso ou o nome do bloco estiver ausente, o bloco não será renderizado na página.

Estrutura de blocos block-structure

As propriedades dos blocos são definidas nos modelos de componentes e persistem como tal no AEM. As propriedades são renderizadas como células na estrutura semelhante à tabela do bloco.

Blocos simples simple

Na forma mais simples, um bloco renderiza cada propriedade em uma única linha/coluna na ordem em que as propriedades são definidas no modelo.

No exemplo a seguir, a imagem é definida primeiro no modelo e o texto em segundo lugar. Assim, eles são renderizados com a imagem em primeiro lugar e o texto em segundo lugar.

{
  "name": "Hero",
  "model": "hero",
  "image": "/content/dam/image.png",
  "imageAlt": "Helix - a shape like a corkscrew",
  "text": "<h1>Welcome to AEM</h1>"
}

<div class="hero">
  <div>
    <div>
      <picture>
        <img src="/content/dam/image.png" alt="Helix - a shape like a corkscrew">
      </picture>
    </div>
  </div>
  <div>
    <div>
      <h1>Welcome to AEM</h1>
    </div>
  </div>
</div>

+---------------------------------------------+
| Hero                                        |
+=============================================+
| ![Helix - a shape like a corkscrew][image0] |
+---------------------------------------------+
| # Welcome to AEM                            |
+---------------------------------------------+

Observe que alguns tipos de valores permitem inferir a semântica na marcação e as propriedades são combinadas em em células únicas. Este comportamento é descrito na seção Inferência de Tipo.

Bloco de valor-chave key-value

Em muitos casos, é recomendável decorar a marcação semântica renderizada, adicionar nomes de classe CSS, adicionar novos nós ou movê-los no DOM e aplicar estilos.

Em outros casos, no entanto, o bloco é lido como uma configuração de par de valores chave.

Um exemplo disso são os metadados de seção. Nesse caso de uso, o bloco pode ser configurado para renderizar como tabela de par de valor chave. Consulte a seção Seções e metadados da seção para obter mais informações.

{
  "name": "Featured Articles",
  "model": "spreadsheet-input",
  "key-value": true,
  "source": "/content/site/articles.json",
  "keywords": ['Developer','Courses'],
  "limit": 4
}

<div class="featured-articles">
  <div>
    <div>source</div>
    <div><a href="/content/site/articles.json">/content/site/articles.json</a></div>
  </div>
  <div>
    <div>keywords</div>
    <div>Developer,Courses</div>
  <div>
  <div>
    <div>limit</div>
    <div>4</div>
  </div>
</div>

+-----------------------------------------------------------------------+
| Featured Articles                                                     |
+=======================================================================+
| source   | [/content/site/articles.json](/content/site/articles.json) |
+-----------------------------------------------------------------------+
| keywords | Developer,Courses                                          |
+-----------------------------------------------------------------------+
| limit    | 4                                                          |
+-----------------------------------------------------------------------+

Blocos de contêiner container

Ambas as estruturas anteriores têm uma única dimensão: a lista de propriedades. Os blocos de contêiner permitem adicionar filhos (geralmente do mesmo tipo ou modelo) e, portanto, são bidimensionais. Esses blocos ainda suportam suas próprias propriedades renderizadas como linhas com uma única coluna primeiro. Mas também permitem adicionar filhos, para os quais cada item é renderizado como linha e cada propriedade como coluna dentro dessa linha.

No exemplo a seguir, um bloco aceita uma lista de ícones vinculados como filhos, onde cada ícone vinculado tem uma imagem e um link. Observe a ID de filtro definida nos dados do bloco para fazer referência à configuração de filtro.

{
  "name": "Our Partners",
  "model": "text-only",
  "filter": "our-partners",
  "text": "<p>Our community of partners is ...</p>",
  "item_0": {
    "model": "linked-icon",
    "image": "/content/dam/partners/foo.png",
    "imageAlt": "Icon of Foo",
    "link": "https://foo.com/"
  },
  "item_1": {
    "model": "linked-icon"
    "image": "/content/dam/partners/bar.png",
    "imageAlt": "Icon of Bar",
    "link": "https://bar.com"
  }
}

<div class="our-partners">
  <div>
    <div>
        Our community of partners is ...
    </div>
  </div>
  <div>
    <div>
      <picture>
         <img src="/content/dam/partners/foo.png" alt="Icon of Foo">
      </picture>
    </div>
    <div>
      <a href="https://foo.com">https://foo.com</a>
    </div>
  </div>
  <div>
    <div>
      <picture>
         <img src="/content/dam/partners/bar.png" alt="Icon of Bar">
      </picture>
    </div>
    <div>
      <a href="https://bar.com">https://bar.com</a>
    </div>
  </div>
</div>

+------------------------------------------------------------ +
| Our Partners                                                |
+=============================================================+
| Our community of partners is ...                            |
+-------------------------------------------------------------+
| ![Icon of Foo][image0] | [https://foo.com](https://foo.com) |
+-------------------------------------------------------------+
| ![Icon of Bar][image1] | [https://bar.com](https://bar.com) |
+-------------------------------------------------------------+

Criação de modelos de conteúdo semântico para blocos creating-content-models

Com a mecânica da estrutura de blocos explicada, é possível criar um modelo de conteúdo que mapeie o conteúdo persistente do AEM de um para um para o nível de entrega.

No início de cada projeto, um modelo de conteúdo deve ser cuidadosamente considerado para cada bloco. Ele deve ser agnóstico em relação à fonte de conteúdo e à experiência de criação para permitir que os autores os alternem ou combinem ao reutilizar implementações e estilos de bloco. Mais detalhes e orientações gerais podem ser encontrados no Modelo de David (tomada 2). Mais especificamente, a coleção de blocos contém um conjunto extenso de modelos de conteúdo para casos de uso específicos de padrões comuns da interface do usuário.

Para a criação WYSIWYG com Edge Delivery Services, isso levanta a questão de como fornecer um modelo atraente de conteúdo semântico quando as informações são criadas com formulários compostos por vários campos, em vez de editar a marcação semântica em contexto, como um rich text.

Para resolver esse problema, há três métodos que facilitam a criação de um modelo de conteúdo atraente:

Inferência de tipo type-inference

Para alguns valores, podemos inferir o significado semântico a partir dos próprios valores. Esses valores incluem:

Todo o resto será renderizado como texto simples.

Recolher Campo field-collapse

O recolhimento de campo é o mecanismo que combina vários valores de campo em um único elemento semântico com base em uma convenção de nomenclatura usando os sufixos Title, Type, MimeType, Alt e Text (todos diferenciam maiúsculas de minúsculas). Qualquer propriedade que termine com qualquer um desses sufixos não será considerada um valor, mas como um atributo de outra propriedade.

Imagens image-collapse

{
  "image": "/content/dam/red-car.png",
  "imageAlt: "A red card on a road"
}

<picture>
  <img src="/content/dam/red-car.png" alt="A red car on a road">
</picture>

![A red car on a road][image0]

Links e botões links-buttons-collapse

{
  "link": "https://www.adobe.com",
  "linkTitle": "Navigate to adobe.com",
  "linkText": "adobe.com",
  "linkType": "primary"
}

<a href="https://www.adobe.com" title="Navigate to adobe.com">adobe.com</a>

<strong>
  <a href="https://www.adobe.com" title="Navigate to adobe.com">adobe.com</a>
</strong>

<em>
  <a href="https://www.adobe.com" title="Navigate to adobe.com">adobe.com</a>
</em>

[adobe.com](https://www.adobe.com "Navigate to adobe.com")
**[adobe.com](https://www.adobe.com "Navigate to adobe.com")**
_[adobe.com](https://www.adobe.com "Navigate to adobe.com")_

Cabeçalhos headings-collapse

{
  "heading": "Getting started",
  "headingType": "h2"
}

<h2>Getting started</h2>

## Getting started

Agrupamento de elementos element-grouping

Embora o recolhimento de campo seja sobre a combinação de várias propriedades em um único elemento semântico, o agrupamento de elementos é sobre a concatenação de vários elementos semânticos em uma única célula. Isso é particularmente útil para casos de uso em que o autor deve ser restrito no tipo e no número de elementos que pode criar.

Por exemplo, um componente de teaser pode permitir que o autor crie apenas um subtítulo, título e uma única descrição de parágrafo combinada com no máximo dois botões de chamada para ação. O agrupamento desses elementos produz uma marcação semântica que pode ser estilizada sem mais ações.

O agrupamento de elementos usa uma convenção de nomenclatura, em que o nome do grupo é separado de cada propriedade no grupo por um sublinhado. O recolhimento de campo das propriedades em um grupo funciona conforme descrito anteriormente.

{
  "name": "teaser",
  "model": "teaser",
  "image": "/content/dam/teaser-background.png",
  "imageAlt": "A group of people sitting on a stage",
  "teaserText_subtitle": "Adobe Experience Cloud"
  "teaserText_title": "Meet the Experts"
  "teaserText_titleType": "h2"
  "teaserText_description": "<p>Join us in this ask me everything session...</p>"
  "teaserText_cta1": "https://link.to/more-details",
  "teaserText_cta1Text": "More Details"
  "teaserText_cta2": "https://link.to/sign-up",
  "teaserText_cta2Text": "RSVP",
  "teaserText_cta2Type": "primary"
}

<div class="teaser">
  <div>
    <div>
      <picture>
        <img src="/content/dam/teaser-background.png" alt="A group of people sitting on a stage">
      </picture>
    </div>
  </div>
  <div>
    <div>
      <p>Adobe Experience Cloud</p>
      <h2>Meet the Experts</h2>
      <p>Join us in this ask me everything session ...</p>
      <p><a href="https://link.to/more-details">More Details</a></p>
      <p><strong><a href="https://link.to/sign-up">RSVP</a></strong></p>
    </div>
  </div>
</div>

+-------------------------------------------------+
| Teaser                                          |
+=================================================+
| ![A group of people sitting on a stage][image0] |
+-------------------------------------------------+
| Adobe Experience Cloud                          |
| ## Welcome to AEM                               |
| Join us in this ask me everything session ...   |
| [More Details](https://link.to/more-details)    |
| [RSVP](https://link.to/sign-up)                 |
+-------------------------------------------------+

Seções e metadados de seção sections-metadata

Da mesma forma que um desenvolvedor pode definir e modelar vários blocos, eles podem definir seções diferentes.

O modelo de conteúdo do Edge Delivery Services permite deliberadamente apenas um único nível de aninhamento, ou seja, qualquer conteúdo ou bloco padrão contido em uma seção. Isso significa que, para ter componentes visuais mais complexos que possam conter outros componentes, eles precisam ser modelados como seções e combinados juntos usando o bloqueio automático do lado do cliente. Exemplos típicos disso são abas e seções recolhíveis, como acordeões.

Uma seção pode ser definida da mesma forma que um bloco, mas com o tipo de recurso core/franklin/components/section/v1/section. As seções podem ter um nome e uma ID de filtro, que são usadas somente pelo Editor Universal, bem como uma ID de modelo, que é usada para renderizar os metadados da seção. O modelo é, dessa forma, o modelo do bloco de metadados da seção, que será anexado automaticamente a uma seção como bloco de valor principal se não estiver vazio.

A ID do modelo e a ID do filtro da seção padrão é section. Ela pode ser usada para alterar o comportamento da seção padrão. O exemplo a seguir adiciona alguns estilos e e uma imagem de plano de fundo ao modelo de metadados da seção.

{
  "id": "section",
  "fields": [
    {
      "component": "multiselect",
      "name": "style",
      "value": "",
      "label": "Style",
      "valueType": "string",
      "options": [
        {
          "name": "Fade in Background",
          "value": "fade-in"
        },
        {
          "name": "Highlight",
          "value": "highlight"
        }
      ]
    },
    {
      "component": "reference",
      "valueType": "string",
      "name": "background",
      "label": "Image",
      "multi": false
    }
  ]
}

O exemplo a seguir define uma seção de guia, que pode ser usada para criar um bloco de guias combinando seções consecutivas com um atributo de dados de título de guia em um bloco de guias durante o bloqueio automático.

{
  "title": "Tab",
  "id": "tab",
  "plugins": {
    "xwalk": {
      "page": {
        "resourceType": "core/franklin/components/section/v1/section",
        "template": {
          "name": "Tab",
          "model": "tab",
          "filter": "section"
        }
      }
    }
  }
}

Metadados de página page-metadata

Os documentos podem ter um bloco de metadados de página,, que é usado para definir quais elementos <meta> são renderizados no <head> de uma página. As propriedades de página das páginas no AEM as a Cloud Service são mapeadas para aquelas que estão disponíveis prontas para uso para Edge Delivery Services, como title, description, keywords, etc.

Antes de explorar mais detalhadamente como definir seus próprios metadados, revise os documentos a seguir para entender o conceito de metadados da página primeiro.

Também é possível definir metadados de página adicionais de duas maneiras.

Planilhas de metadados metadata-spreadsheets

É possível definir metadados por caminho ou por padrão de caminho de uma maneira semelhante a uma tabela no AEM as a Cloud Service. Há uma interface de criação para dados semelhantes a tabelas disponíveis semelhante ao Excel ou ao Google Sheets.

Para criar essa tabela, crie uma página e use o modelo de Metadados no console Sites.

Nas propriedades de página da planilha, defina os campos de metadados necessários junto com o URL. Em seguida, adicione metadados por caminho ou padrão de caminho de página.

Verifique se a planilha foi adicionada ao mapeamento de caminho antes de publicá-la.

{
  "mappings": [
    "/content/site/:/",
    "/content/site/metadata:/metadata.json"
  ]
}

Propriedades da página page-properties

Muitas das propriedades de página padrão disponíveis no AEM são mapeadas para os respectivos metadados de página em um documento. Isso inclui, por exemplo, title, description, robots, canonical url ou keywords. Algumas propriedades específicas do AEM também estão disponíveis:

Também é possível definir um modelo de componente para metadados de página personalizados, que será disponibilizado ao autor como uma guia da caixa de diálogo de propriedades da página do AEM Sites.

Para fazer isso, crie um modelo de componente com a ID page-metadata.

{
  "id": "page-metadata",
  "fields": [
    {
      "component": "text",
      "name": "theme",
      "label": "Theme"
    }
  ]
}

Próximas etapas next-steps

Agora que você sabe como modelar o conteúdo, é possível criar blocos para seus próprios Edge Delivery Services com o projeto de criação WYSIWYG.

Consulte o documento Criando Blocos Instrumentados para uso com o Editor Universal para saber como criar blocos instrumentados para uso com o Editor Universal em criação WYSIWYG com projetos Edge Delivery Services.

Se você já estiver familiarizado com a criação de blocos, consulte o documento Guia de Introdução do Desenvolvedor para criação WYSIWYG com o Edge Delivery Services para que você possa começar a usar um novo site do Adobe Experience Manager usando o Edge Delivery Services e o Editor Universal para criação de conteúdo.