Para marcar o conteúdo e aproveitar a infraestrutura de Marcação de AEM:
A tag deve existir como um nó do tipo [cq:Tag](#tags-cq-tag-node-type)
no nó raiz de taxonomia
O NodeType do nó de conteúdo marcado deve incluir a combinação cq:Taggable
O TagID é adicionado à propriedade cq:tags
do nó de conteúdo e resolve-se para um nó do tipo [cq:Tag](#tags-cq-tag-node-type)
A declaração de uma tag é capturada no repositório em um nó do tipo cq:Tag.
Uma marca pode ser uma palavra simples (por exemplo, o céu) ou representar uma taxonomia hierárquica (por exemplo, fruta/maçã, ou seja, tanto o fruto genérico como a maçã mais específica).
As tags são identificadas por uma TagID exclusiva.
Uma tag tem informações meta opcionais, como um título, títulos localizados e uma descrição. O título deve ser exibido nas interfaces do usuário em vez da TagID, quando presente.
A estrutura de marcação também fornece a capacidade de restringir autores e visitantes do site a usar somente tags específicas e predefinidas.
o tipo de nó é cq:Tag
o nome do nó é um componente de [TagID](#tagid)
o [TagID](#tagid)
sempre inclui uma namespace
propriedade opcional jcr:title
(o Título a ser exibido na interface do usuário)
propriedade opcional jcr:description
ao conter nós filho, é chamado de tag de container
é armazenado no repositório abaixo de um caminho base chamado nó raiz de taxonomia
Uma TagID identifica um caminho que é resolvido para um nó de tag no repositório.
Geralmente, a TagID é uma TagID abreviada que começa com a namespace ou pode ser uma TagID absoluta que começa no nó raiz de taxonomia.
Quando o conteúdo é marcado, se ainda não existir, a propriedade [cq:tags](#tagged-content-cq-tags-property)
é adicionada ao nó de conteúdo e a TagID é adicionada ao valor da matriz String da propriedade.
A TagID consiste em uma namespace seguida pela TagID local. Container tagshave subtags que representam uma ordem hierárquica na taxonomia. As subtags podem ser usadas para referenciar tags como qualquer TagID local. Por exemplo, é permitida a marcação do conteúdo com "fruta", mesmo que se trate de uma etiqueta de container com sub-marcas, como "fruta/maçã" e "fruta/banana".
O nó raiz de taxonomia é o caminho base para todas as tags no repositório. O nó raiz de taxonomia deve e não ser um nó do tipo cq :Tag
.
No AEM, o caminho base é /content/ cq :tags
e o nó raiz é do tipo cq :Folder
.
Namespaces permitem agrupar itens. O caso de uso mais comum é ter uma namespace por site (web)site (por exemplo, público, interno e portal) ou por aplicativo maior (por exemplo, WCM, Ativos, Comunidades), mas as namespaces podem ser usadas para várias outras necessidades. As namespaces são usadas na interface do usuário para mostrar apenas o subconjunto de tags (ou seja, tags de determinada namespace) que se aplica ao conteúdo atual.
A namespace da tag é o primeiro nível na subárvore de taxonomia, que é o nó imediatamente abaixo do nó raiz de taxonomia. Uma namespace é um nó do tipo cq:Tag
cujo pai não é um tipo de nó cq:Tag
.
Todas as tags têm uma namespace. Se nenhuma namespace for especificada, a tag será atribuída à namespace padrão, que é TagID default
(o Título é Standard Tags),
que é /content/cq:tags/default.
Uma tag de container é um nó do tipo cq:Tag
que contém qualquer número e tipo de nós secundários, o que permite aprimorar o modelo de tag com metadados personalizados.
Além disso, as tags de container (ou super tags) em uma taxonomia servem como subsoma de todas as subtags: por exemplo, considera-se que o conteúdo marcado com frutas/maçãs também é marcado com frutos, ou seja, procurar por conteúdo marcado apenas com frutos também encontraria o conteúdo marcado com frutas/maçã.
Se a ID da tag contiver dois pontos ":", o dois pontos separará a namespace da tag ou subtaxonomia, que são então separados por barras normais "/". Se a ID da tag não tiver dois pontos, a namespace padrão será implícita.
O local padrão e único das tags está abaixo das tags /content/cq:.
A tag que faz referência a caminhos ou caminhos não existentes que não apontam para um nó cq:Tag é considerada inválida e é ignorada.
A tabela a seguir mostra algumas TagIDs de amostra, seus elementos e como a TagID é resolvida para um caminho absoluto no repositório:
A tabela a seguir mostra algumas TagIDs de amostra, seus elementos e como a TagID é resolvida para um caminho absoluto no repositório:
A tabela a seguir mostra algumas TagIDs de amostra, seus elementos e como a TagID é resolvida para um caminho absoluto no repositório:
TagID |
Namespace | ID local | Tags de container | Marca Folha | Repositório Caminho absoluto da tag |
represa:fruta/maçã/queimadura | barragem | fruta/maçã/queimadura | fruta, maçã | braquia | /content/cq:tags/dam/frus/apple/braeburn |
cor/vermelho | default | cor/vermelho | cor | red | /content/cq:tags/default/color/red |
céu | default | céu | (nenhum) | céu | /content/cq:tags/default/sky |
barragem: | barragem | (nenhum) | (nenhum) | (nenhum, a namespace) | /content/cq:tags/dam |
/content/cq:tags/categoria/car | categoria | carro | carro | carro | /content/cq:tags/categoria/car |
Quando a tag inclui a string de título opcional ( jcr:title
), é possível localizar o título para exibição adicionando a propriedade jcr:title.<locale>
.
Para obter mais detalhes, consulte
As tags existem como nós no repositório sob o nó raiz de taxonomia. Permitir ou negar que autores e visitantes do site criem tags em uma determinada namespace pode ser alcançado ao configurar ACLs apropriadas no repositório.
Além disso, negar permissões de leitura para determinadas tags ou namespaces controlará a capacidade de aplicar tags a um conteúdo específico.
Uma prática típica inclui:
Permitindo o acesso de gravação de tag-administrators
grupo/função a todas as namespaces (adicione/modifique em /content/cq:tags
). Este grupo vem com AEM prontos.
Permitir que usuários/autores leiam acesso a todas as namespaces que deveriam ser legíveis para eles (na maioria das vezes, todas).
Permitir que usuários/autores gravem acesso às namespaces nas quais as tags devem ser definidas livremente pelos usuários/autores (add_node em /content/cq:tags/some_namespace
)
Para que os desenvolvedores de aplicativos anexem a marcação a um tipo de conteúdo, o registro do nó (CND) deve incluir a combinação cq:Taggable
ou cq:OwnerTaggable
.
A combinação cq:OwnerTaggable
, que herda de cq:Taggable
, serve para indicar que o conteúdo pode ser classificado pelo proprietário/autor. No AEM, é apenas um atributo do nó cq:PageContent
. A combinação cq:OwnerTaggable
não é exigida pela estrutura de marcação.
É recomendável ativar somente tags no nó de nível superior de um item de conteúdo agregado (ou em seu nó jcr:content). Os exemplos incluem:
páginas ( cq:Page
) onde o nó jcr:content
é do tipo cq:PageContent
que inclui a combinação cq:Taggable
.
ativos ( cq:Asset
) em que o nó jcr:content/metadata
sempre tem a combinação cq:Taggable
.
As definições de Tipo de nó existem no repositório como arquivos CND. A notação CND é definida como parte da documentação JCR here.
As definições essenciais para os tipos de nó incluídos no AEM são as seguintes:
[cq:Tag] > mix:title, nt:base
orderable
- * (undefined) multiple
- * (undefined)
+ * (nt:base) = cq:Tag version
[cq:Taggable]
mixin
- cq:tags (string) multiple
[cq:OwnerTaggable] > cq:Taggable
mixin
A propriedade cq:tags
é uma matriz String usada para armazenar uma ou mais TagIDs quando são aplicadas ao conteúdo por autores ou visitantes do site. A propriedade só tem significado quando adicionada a um nó definido com a combinação [cq:Taggable](#taggable-content-cq-taggable-mixin)
.
Para aproveitar AEM funcionalidade de marcação, os aplicativos desenvolvidos personalizados não devem definir propriedades de tags diferentes de cq:tags
.
A seguir está uma descrição dos efeitos no repositório ao mover ou unir tags usando o console de marcação:
Quando uma tag A é movida ou unida na tag B sob /content/cq:tags
:
cq:movedTo
.cq:backlinks
.cq:movedTo
aponta para a tag B. Essa propriedade significa que a tag A foi movida ou mesclada para a tag B. Mover a tag B atualizará essa propriedade de acordo. A tag A fica então oculta e é mantida somente no repositório para resolver IDs de tag em nós de conteúdo que apontam para a tag A. O coletor de lixo de tags remove tags como a tag A, uma vez que nenhum nó de conteúdo aponta para elas.
Um valor especial para a propriedade cq:movedTo
é nirvana
: ela é aplicada quando a tag é excluída, mas não pode ser removida do repositório porque há subtags com cq:movedTo
que devem ser mantidas.
A propriedade cq:movedTo
só será adicionada à tag movida ou unida se uma dessas condições for atendida:
cq:backlinks
mantém as referências na outra direção, isto é, mantém uma lista de todas as tags que foram movidas para ou mescladas com a tag B. Isso é necessário principalmente para manter cq:movedTo
as propriedades atualizadas quando a tag B também é movida/unida/excluída ou quando a tag B é ativada, nesse caso, todas as tags de backlinks também devem ser ativadas.
A propriedade cq:backlinks
só será adicionada à tag movida ou unida se uma dessas condições for atendida:
A leitura de uma propriedade cq:tags
de um nó de conteúdo envolve a seguinte resolução:
Se não houver correspondência em /content/cq:tags
, nenhuma tag será retornada.
Se a tag tiver uma propriedade cq:movedTo
definida, a ID da tag referenciada será seguida.
Essa etapa é repetida, contanto que a tag seguida tenha uma propriedade cq:movedTo
.
Se a tag seguida não tiver uma propriedade cq:movedTo
, a tag será lida.
Para publicar a alteração quando uma tag tiver sido movida ou unida, o nó cq:Tag
e todos os seus backlinks devem ser replicados: isso é feito automaticamente quando a tag é ativada no console de administração de tags.
Atualizações posteriores para a propriedade cq:tags
da página limpam automaticamente as referências "antigas". Isso é acionado porque a resolução de uma tag movida pela API retorna a tag de destino, fornecendo assim a ID da tag de destino.
O movimento das tags é diferente da migração das tags.
As tags a partir de Experience Manager 6.4 são armazenadas em /content/cq:tags
, que foram armazenadas anteriormente em /etc/tags
. No entanto, em cenários em que o Adobe Experience Manager foi atualizado da versão anterior, as tags ainda estão presentes no local antigo /etc/tags
. Em sistemas atualizados, as tags precisam ser migradas em /content/cq:tags
.
Na página Propriedades da página de tags, recomenda-se usar a ID da tag (geometrixx-outdoors:activity/biking
) em vez de codificar o caminho da base da tag (por exemplo, /etc/tags/geometrixx-outdoors/activity/biking
).
Para lista de tags, com.day.cq.tagging.servlets.TagListServlet
pode ser usado.
Recomenda-se usar a API do gerenciador de tags como recurso.
No start do componente, a API do TagManager detecta se é uma instância AEM atualizada. No sistema atualizado, as tags são armazenadas em /etc/tags
.
A API do TagManager é executada no modo de compatibilidade com versões anteriores, o que significa que a API usa /etc/tags
como caminho base. Caso contrário, ele usa a nova localização /content/cq:tags
.
Atualize o local das tags.
Depois de migrar as tags para o novo local, execute o seguinte script:
import org.apache.sling.api.resource.*
import javax.jcr.*
ResourceResolverFactory resourceResolverFactory = osgi.getService(ResourceResolverFactory.class);
ResourceResolver resolver = resourceResolverFactory.getAdministrativeResourceResolver(null);
Session session = resolver.adaptTo(Session.class);
def queryManager = session.workspace.queryManager;
def statement = "/jcr:root/content/cq:tags//element(*, cq:Tag)[jcr:contains(@cq:movedTo,\'/etc/tags\') or jcr:contains(@cq:backlinks,\'/etc/tags\')]";
def query = queryManager.createQuery(statement, "xpath");
println "query = ${query.statement}\n";
def tags = query.execute().getNodes();
tags.each { node ->
def tagPath = node.path;
println "tag = ${tagPath}";
if(node.hasProperty("cq:movedTo") && node.getProperty("cq:movedTo").getValue().toString().startsWith("/etc/tags"))
{
def movedTo = node.getProperty("cq:movedTo").getValue().toString();
println "cq:movedTo = ${movedTo} \n";
movedTo = movedTo.replace("/etc/tags","/content/cq:tags");
node.setProperty("cq:movedTo",movedTo);
} else if(node.hasProperty("cq:backlinks")){
String[] backLinks = node.getProperty("cq:backlinks").getValues();
int count = 0;
backLinks.each { value ->
if(value.startsWith("/etc/tags")){
println "cq:backlinks = ${value}\n";
backLinks[count] = value.replace("/etc/tags","/content/cq:tags");
}
count++;
}
node.setProperty("cq:backlinks",backLinks);
}
}
session.save();
println "---------------------------------Success-------------------------------------"
O script obtém todas as tags que têm /etc/tags
no valor da propriedade cq:movedTo/cq:backLinks
. Em seguida, ele repete pelo conjunto de resultados obtidos e resolve os valores das propriedades cq:movedTo
e cq:backlinks
para os caminhos /content/cq:tags
(no caso em que /etc/tags
é detectado no valor).
A interface clássica não é compatível com zero tempo de inatividade e não oferece suporte para o novo caminho de base de tags. Se você deseja usar a interface clássica que /etc/tags
precisa ser criada, seguido por cq-tagging
reinicialização do componente.
No caso de instâncias de AEM atualizadas suportadas pela API do TagManager e executadas na interface clássica:
Depois que as referências ao caminho base da tag antiga /etc/tags
forem substituídas usando o tagId ou o novo local da tag /content/cq:tags
, você poderá migrar as tags para o novo local /content/cq:tags
no CRX, seguido da reinicialização do componente.
Depois de migrar as tags para o novo local, execute o script mencionado acima.