Modelagem de conteúdo para criação no WYSIWYG com projetos Edge Delivery Services content-modeling
Saiba como a modelagem de conteúdo funciona para a criação de WYSIWYG com projetos Edge Delivery Services e como modelar seu próprio conteúdo.
Pré-requisitos prerequisites
Os projetos que usam a Criação de 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 do 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.
- Texto: Rich text (incluindo elementos de lista e texto forte ou itálico)
- Título: texto, tipo (h1-h6)
- Imagem: Source, descrição
- Botão: texto, título, url, tipo (padrão, primário, secundário)
O modelo desses componentes faz parte da Estrutura para criação do 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 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 do WYSIWYG com o 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:
- É necessário usar o tipo de recurso
core/franklin/components/block/v1/block
, a implementação genérica da lógica de bloqueio no AEM. - É necessário definir o nome do bloco, que será renderizado no cabeçalho da tabela do bloco.
- O nome do bloco é usado para buscar o estilo e o script corretos para decorar o bloco.
- Pode definir um ID de modelo.
- A ID do modelo é uma referência ao modelo do componente, que define os campos disponíveis para o autor no painel de propriedades.
- Pode definir um ID de filtro.
- A ID do filtro é uma referência ao filtro do componente, que permite alterar o comportamento de criação, por exemplo, limitando quais filhos podem ser adicionados ao bloco ou seção, ou quais recursos de RTE estão habilitados.
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.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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 de 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 no 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:
- Imagens - Se uma referência a um recurso no AEM for um ativo com um tipo MIME começando com
image/
, a referência será renderizada como<picture><img src="${reference}"></picture>
. - Links - Se uma referência existir no AEM e não for uma imagem, ou se o valor começar com
https?://
ou#
, a referência será renderizada como<a href="${reference}">${reference}</a>
. - Rich Text - Se um valor aparado começa com um parágrafo (
p
,ul
,ol
,h1
-h6
, etc.), o valor é renderizado como rich text. - Nomes de Classe - A propriedade
classes
é tratada como opções de bloco e renderizada no cabeçalho da tabela para blocos simples ou como lista de valores para itens em um bloco de contêiner . É útil se você deseja estilizar um bloco de forma diferente,, mas não precisa criar um bloco totalmente novo. - Listas de Valores - Se um valor for uma propriedade de vários valores e o primeiro valor não for nenhum dos anteriores, todos os valores serão concatenados como uma lista separada por vírgulas.
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
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
Links e botões links-buttons-collapse
code language-json |
---|
|
Nenhum linkType
ou linkType=default
code language-html |
---|
|
linkType=primary
code language-html |
---|
|
linkType=secondary
code language-html |
---|
|
code language-text |
---|
|
Cabeçalhos headings-collapse
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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.
code language-json |
---|
|
code language-html |
---|
|
code language-text |
---|
|
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 obter mais detalhes, consulte o documento Usando Planilhas para Gerenciar Dados Tabulares para obter mais informações.
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:
cq:lastModified
comomodified-time
no formato ISO8601- A hora em que o documento foi publicado pela última vez como
published-time
no formato ISO8601 cq:tags
comocq-tags
como uma lista separada por vírgulas das IDs de marcas.
Também é possível definir um modelo de componente para metadados de página personalizados, que será disponibilizado ao autor no Editor universal.
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 conteúdo, pode criar blocos para seus próprios Edge Delivery Services com o projeto de criação do WYSIWYG.
Consulte o documento Criação de blocos instrumentados para uso com o Editor universal para saber como criar blocos instrumentados para uso com o Editor universal na criação de projetos do WYSIWYG com Edge Delivery Services.
Se você já estiver familiarizado com a criação de blocos, consulte o documento Guia de Introdução ao Desenvolvedor para criação no 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.