Per assegnare tag ai contenuti e sfruttare l’infrastruttura di assegnazione tag AEM :
Il tag deve esistere come nodo di tipo [cq:Tag](#tags-cq-tag-node-type)
in nodo principale tassonomia
NodeType del nodo di contenuto con tag deve includere cq:Taggable
mescolina
La TagID viene aggiunto al nodo del contenuto cq:tags
e risolve in un nodo di tipo [cq:Tag](#tags-cq-tag-node-type)
La dichiarazione di un tag viene acquisita nell’archivio in un nodo di tipo cq:Tag.
Un tag può essere una parola semplice (ad esempio cielo) o rappresentare una tassonomia gerarchica (ad esempio frutta/mela, che significa sia il frutto generico che la mela più specifica).
I tag sono identificati da un TagID univoco.
Un tag contiene metadati facoltativi, ad esempio un titolo, titoli localizzati e una descrizione. Il titolo deve essere visualizzato nelle interfacce utente invece del tagID, se presente.
Il framework di assegnazione tag consente inoltre di limitare gli autori e i visitatori del sito a utilizzare solo tag predefiniti specifici.
tipo di nodo cq:Tag
il nome del nodo è un componente del [TagID](#tagid)
la [TagID](#tagid)
include sempre namespace
facoltativo jcr:title
(Titolo da visualizzare nell’interfaccia utente)
facoltativo jcr:description
property
quando contengono nodi figlio, è indicato come tag contenitore
è memorizzato nel repository sotto un percorso di base denominato nodo principale tassonomia
Un TagID identifica un percorso che viene risolto in un nodo di tag nell'archivio.
In genere, il TagID è un TagID abbreviato che inizia con lo spazio dei nomi o può essere un TagID assoluto a partire da nodo principale tassonomia.
Quando il contenuto è contrassegnato, se non esiste ancora, la [cq:tags](#tagged-content-cq-tags-property)
viene aggiunta al nodo di contenuto e il tagID viene aggiunto al valore dell'array String della proprietà.
Il TagID è costituito da un namespace seguito dal tagID locale. Tag contenitore dispongono di tag secondari che rappresentano un ordine gerarchico nella tassonomia. I tag secondari possono essere utilizzati per fare riferimento ai tag come qualsiasi altro TagID locale. Ad esempio, è consentita l’assegnazione di tag al contenuto con "frutta", anche se si tratta di un tag contenitore con tag secondari, come "frutta/mela" e "frutta/banana".
Il nodo principale della tassonomia è il percorso di base per tutti i tag nel repository. Il nodo principale della tassonomia deve not essere un nodo di tipo cq :Tag
.
In AEM, il percorso di base è /content/ cq :tags
e il nodo principale è di tipo cq :Folder
.
I namespace consentono di raggruppare gli elementi. Il caso d’uso più tipico è quello di avere uno spazio dei nomi per sito (web) (ad esempio pubblico, interno e portale) o per applicazione più grande (ad esempio WCM, Assets, Communities), ma i namespace possono essere utilizzati per varie altre esigenze. I namespace vengono utilizzati nell’interfaccia utente per mostrare solo il sottoinsieme di tag (ovvero i tag di un determinato namespace) applicabile al contenuto corrente.
Lo spazio dei nomi del tag è il primo livello della sottostruttura della tassonomia, che è il nodo immediatamente sotto la nodo principale tassonomia. Uno spazio dei nomi è un nodo di tipo cq:Tag
il cui genitore non è un cq:Tag
tipo di nodo.
Tutti i tag hanno uno spazio dei nomi. Se non viene specificato alcun namespace, il tag viene assegnato allo spazio dei nomi predefinito, che è TagID default
(Il titolo è Standard Tags),
che /content/cq:tags/default.
Un tag contenitore è un nodo di tipo cq:Tag
contenente qualsiasi numero e tipo di nodi figlio, che consente di migliorare il modello di tag con metadati personalizzati.
Inoltre, i tag contenitore (o super tag) in una tassonomia fungono da sotto-somma di tutti i tag secondari: ad esempio, il contenuto contrassegnato con frutta/mela è considerato anche marcato con frutta, cioè la ricerca di contenuto semplicemente marcato con frutta trova anche il contenuto marcato con frutta/mela.
Se l’ID del tag contiene due punti ":", il due punti separa lo spazio dei nomi dal tag o dalla tassonomia secondaria, che vengono quindi separati con le normali barre "/". Se l’ID del tag non ha due punti, viene implicito il namespace predefinito.
La posizione standard e unica dei tag è sotto /content/cq:tags.
I tag che fanno riferimento a percorsi o percorsi non esistenti che non puntano a un nodo cq:Tag sono considerati non validi e vengono ignorati.
La tabella seguente mostra alcuni tagID di esempio, i relativi elementi e il modo in cui il tagID viene risolto in un percorso assoluto nell’archivio:
La tabella seguente mostra alcuni tagID di esempio, i relativi elementi e il modo in cui il tagID viene risolto in un percorso assoluto nell’archivio :
ID tag |
Namespace | ID locale | Tag contenitore | Tag foglia | Archivio Percorso tag assoluto |
dam:frutta/mela/braeburn | diga | frutta/mela/cervello | frutta, mela | burrasca | /content/cq:tags/dam/fruit/apple/braeburn |
colore/rosso | impostazione predefinita | colore/rosso | color | rosso | /content/cq:tags/default/color/red |
cielo | impostazione predefinita | cielo | (nessuno) | cielo | /content/cq:tags/default/sky |
dam: | diga | (nessuno) | (nessuno) | (Nessuno, spazio dei nomi) | /content/cq:tags/dam |
/content/cq:tags/category/car | categoria | auto | auto | auto | /content/cq:tags/category/car |
Quando il tag include la stringa del titolo opzionale ( jcr:title
) è possibile localizzare il titolo per la visualizzazione aggiungendo la proprietà jcr:title.<locale>
.
Per ulteriori dettagli vedi
I tag esistono come nodi nell’archivio sotto nodo principale tassonomia. È possibile consentire o negare agli autori e ai visitatori del sito di creare tag in un dato spazio dei nomi impostando ACL appropriati nell’archivio.
Inoltre, negare le autorizzazioni di lettura per alcuni tag o namespace controllerà la possibilità di applicare tag a contenuti specifici.
Una pratica tipica include:
Consentire la tag-administrators
accesso in scrittura di gruppo/ruolo a tutti i namespace (aggiungere/modificare in /content/cq:tags
). Questo gruppo viene fornito con AEM preconfigurato.
Consentire agli utenti/autori di accedere in lettura a tutti i namespace che dovrebbero essere leggibili per loro (per lo più tutti).
Consentire a utenti/autori di accedere in scrittura a quei namespace in cui i tag devono essere liberamente definibili da utenti/autori (aggiungi_nodo in /content/cq:tags/some_namespace
)
Per consentire agli sviluppatori di applicazioni di allegare tag a un tipo di contenuto, la registrazione del nodo (CND) deve includere cq:Taggable
miscelazione o cq:OwnerTaggable
mixin.
La cq:OwnerTaggable
mixin, che eredita da cq:Taggable
, indica che il contenuto può essere classificato dal proprietario/autore. In AEM, è solo un attributo del cq:PageContent
nodo. La cq:OwnerTaggable
il mixin non è richiesto dal framework di assegnazione tag.
Si consiglia di abilitare solo i tag sul nodo di primo livello di un elemento di contenuto aggregato (o sul relativo nodo jcr:content). Gli esempi includono:
pagine ( cq:Page
) dove jcr:content
il nodo è di tipo cq:PageContent
che include cq:Taggable
mixin.
risorse ( cq:Asset
) dove jcr:content/metadata
il nodo ha sempre cq:Taggable
mixin.
Le definizioni dei tipi di nodo esistono nell’archivio come file CND. La notazione CND è definita come parte della documentazione JCR qui.
Le definizioni essenziali per i tipi di nodo inclusi in AEM sono le seguenti:
[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
La cq:tags
è un array String utilizzato per memorizzare uno o più tagID applicati al contenuto da autori o visitatori del sito. La proprietà ha un significato solo quando viene aggiunta a un nodo definito con [cq:Taggable](#taggable-content-cq-taggable-mixin)
mixin.
Per sfruttare AEM funzionalità di assegnazione tag, le applicazioni sviluppate personalizzate non devono definire proprietà di tag diverse da cq:tags
.
Di seguito è riportata una descrizione degli effetti nell’archivio durante lo spostamento o l’unione dei tag utilizzando Console di assegnazione tag:
Quando un tag A viene spostato o unito nel tag B in /content/cq:tags
:
cq:movedTo
proprietà.cq:backlinks
proprietà.cq:movedTo
fa riferimento al tag B. Questa proprietà significa che il tag A è stato spostato o unito nel tag B. Lo spostamento del tag B comporterà l’aggiornamento di questa proprietà di conseguenza. Il tag A è quindi nascosto e viene mantenuto nell’archivio solo per risolvere gli ID tag nei nodi di contenuto che puntano al tag A. Il tag garbage Collector rimuove i tag come il tag A una volta nessun altro nodo di contenuto li punta.
Un valore speciale per cq:movedTo
è nirvana
: viene applicata quando il tag viene eliminato ma non può essere rimosso dall’archivio perché sono presenti tag secondari con un cq:movedTo
deve essere mantenuto.
La cq:movedTo
viene aggiunta al tag spostato o unito solo se viene soddisfatta una delle seguenti condizioni:
cq:backlinks
mantiene i riferimenti nell’altra direzione, ovvero mantiene un elenco di tutti i tag spostati o uniti al tag B. Questo è richiesto principalmente per mantenere cq:movedTo
le proprietà sono aggiornate anche quando il tag B viene spostato/unito/eliminato o quando il tag B viene attivato, nel qual caso devono essere attivati anche tutti i suoi tag backlink.
La cq:backlinks
viene aggiunta al tag spostato o unito solo se viene soddisfatta una delle seguenti condizioni:
Lettura di un cq:tags
di un nodo di contenuto comporta la seguente risoluzione:
Se non c'è alcuna corrispondenza in /content/cq:tags
, non viene restituito alcun tag.
Se il tag ha un cq:movedTo
impostato sulla proprietà , viene seguito l'ID tag di riferimento.
Questo passaggio viene ripetuto purché il tag seguito abbia un cq:movedTo
proprietà.
Se il tag seguito non ha un cq:movedTo
, il tag viene letto.
Per pubblicare la modifica quando un tag è stato spostato o unito, l’ cq:Tag
il nodo e tutti i suoi backlink devono essere replicati: questa operazione viene eseguita automaticamente quando il tag viene attivato nella console di amministrazione dei tag.
Aggiornamenti successivi al cq:tags
la proprietà pulisce automaticamente i riferimenti "vecchi". Questo viene attivato perché la risoluzione di un tag spostato attraverso l'API restituisce il tag di destinazione, fornendo così l'ID del tag di destinazione.
Lo spostamento dei tag è diverso dalla migrazione dei tag.
Experience Manager 6.4 e successivi i tag sono memorizzati in /content/cq:tags
, precedentemente immagazzinati in /etc/tags
. Tuttavia, negli scenari in cui Adobe Experience Manager è stato aggiornato dalla versione precedente, i tag sono ancora presenti nella vecchia posizione /etc/tags
. Nei sistemi aggiornati i tag devono essere migrati in /content/cq:tags
.
Nelle Proprietà pagina della pagina dei tag , si consiglia di utilizzare l’ID tag (geometrixx-outdoors:activity/biking
) invece di codificare il percorso di base del tag (ad esempio, /etc/tags/geometrixx-outdoors/activity/biking
).
Per elencare i tag, com.day.cq.tagging.servlets.TagListServlet
può essere utilizzato.
È consigliabile utilizzare l’API di gestione tag come risorsa.
All’inizio del componente, l’API TagManager rileva se si tratta di un’istanza AEM aggiornata. Nel sistema aggiornato, i tag vengono memorizzati in /etc/tags
.
L’API TagManager viene quindi eseguita in modalità di retrocompatibilità, il che significa che l’API utilizza /etc/tags
come percorso di base. In caso contrario, utilizza una nuova posizione /content/cq:tags
.
Aggiorna la posizione dei tag.
Dopo aver trasferito i tag nella nuova posizione, esegui il seguente 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-------------------------------------"
Lo script recupera tutti i tag che hanno /etc/tags
nel valore di cq:movedTo/cq:backLinks
proprietà. Quindi esegue un'iterazione del set di risultati recuperato e risolve il cq:movedTo
e cq:backlinks
valori delle proprietà su /content/cq:tags
(nel caso in cui /etc/tags
viene rilevato nel valore).
L’interfaccia classica non è conforme allo zero tempi di inattività e non supporta il nuovo percorso di base dei tag. Se desideri utilizzare l’interfaccia classica anziché /etc/tags
deve essere creato e cq-tagging
riavvio del componente.
In caso di istanze AEM aggiornate supportate dall'API TagManager ed eseguite nell'interfaccia classica:
Una volta fa riferimento al vecchio percorso di base tag /etc/tags
vengono sostituiti utilizzando tagId o nuova posizione tag /content/cq:tags
, puoi migrare i tag nella nuova posizione /content/cq:tags
in CRX seguito dal riavvio del componente.
Dopo aver trasferito i tag nella nuova posizione, esegui lo script menzionato sopra.