Versehen Sie Inhalte mit Tags und nutzen Sie die AEM-Tagging-Infrastruktur wie folgt:
Das Tag muss unterhalb des cq:Tag
Stammknotens der Taxonomie als Knoten vom Typ vorhanden sein.
Der NodeType des mit Tags versehenen Inhaltsknotens muss das Mixin cq:Taggable
beinhalten.
Die TagID wird der Eigenschaft cq:tags
des Inhaltsknotens hinzugefügt und wird zu einem Knoten des Typs cq:Tag
aufgelöst
Die Deklaration eines Tags wird im Repository in einem Knoten des Typs cq:Tag.
erfasst
Ein Tag kann ein einfaches Wort (z. B. Himmel) sein oder eine hierarchische Taxonomie (z. B. Frucht/Apfel, womit sowohl die Frucht im Allgemeinen als auch der Apfel im Speziellen gemeint sind) darstellen.
Tags werden anhand einer eindeutigen Tag-ID identifiziert.
Ein Tag weist optionale Metadaten auf, z. B. einen Titel, lokalisierte Titel und eine Beschreibung. Der Titel sollte, falls vorhanden, auf Benutzeroberflächen anstelle der Tag-ID angezeigt werden.
Das Tagging-Framework bietet außerdem die Möglichkeit, Autoren und Websitebesuchern die Verwendung bestimmter, vordefinierter Tags vorzugeben.
node type is cq:Tag
Knotenname ist eine Komponente von TagID
TagID
enthält immer einen Namensraum
optional jcr:title
-Eigenschaft (der Titel, der in der Benutzeroberfläche angezeigt werden soll)
optional jcr:description
-Eigenschaft
wird als Container-Tag bezeichnet, wenn untergeordnete Knoten enthalten sind
wird im Repository unterhalb eines Basispfads gespeichert, der als Stammknoten der Taxonomie bezeichnet wird
Eine Tag-ID identifiziert einen Pfad, der einen Tag-Knoten im Repository ergibt.
Normalerweise ist die TagID eine kurze TagID, die mit dem Namensraum beginnt, oder eine absolute TagID, beginnend mit dem taxonomy-Stammknoten.
Wenn Inhalte mit Tags versehen werden, aber noch nicht vorhanden sind, wird dem Inhaltsknoten die Eigenschaft cq:tags
und dem String-Array-Wert die Tag-ID hinzugefügt.
Die Tag-ID besteht aus einem Namespace gefolgt von der lokalen Tag-ID. Container-Tags weisen untergeordnete Tags auf, die eine hierarchische Reihenfolge in der Taxonomie darstellen. Unter-Tags können verwendet werden, um Tags zu referenzieren, die mit jeder lokalen TagID übereinstimmen. So ist beispielsweise das Markieren von Inhalten mit "Obst"zulässig, auch wenn es sich um ein Container-Tag mit Untermarken wie "Obst/Apfel"und "Obst/Banane"handelt.
Der Stammknoten der Taxonomie ist der Basispfad für alle Tags im Repository. Der taxonomische Stammknoten muss nicht ein Knoten des Typs cq :Tag
sein.
In AEM ist der Basispfad /content/ cq :tags
und der Stammknoten vom Typ cq :Folder
.
Namespaces ermöglichen das Gruppieren von Elementen. Der typischste Anwendungsfall besteht darin, einen Namensraum pro (Web-)Site (z. B. öffentlich, intern und portal) oder pro größere Anwendung (z. B. WCM, Assets, Communities) zu haben, aber Namensraum können für verschiedene andere Zwecke verwendet werden. Namespaces werden in der Benutzeroberfläche verwendet, um nur die Untergruppe von Tags (d. h. die Tags eines bestimmten Namespace) anzuzeigen, die auf den aktuellen Inhalt anwendbar sind.
Der Namespace des Tags ist die erste Ebene im Teilbaum der Taxonomie, der den Knoten direkt unterhalb des Stammknotens der Taxonomie darstellt. Ein Namensraum ist ein Knoten des Typs cq:Tag
, dessen übergeordnetes Element kein cq:Tag
Node-Typ ist.
Alle Tags haben einen Namespace. Wenn kein Namensraum angegeben ist, wird das Tag dem standardmäßigen Namensraum zugewiesen, d. h. TagID default
( ist Standard Tags),
d. h. /content/cq:tags/default.
Container-Tags sind Knoten vom Typ cq:Tag
, die eine beliebige Anzahl untergeordneter Knoten von beliebigen Typen enthalten. Das ermöglicht die Erweiterung des Tag-Modells mit benutzerdefinierten Metadaten.
Darüber hinaus dienen Container-Tags (oder Super-Tags) in einer Taxonomie als Untersummierung aller untergeordneten Tags: Beispielsweise werden Inhalte, die mit dem Tag „Frucht/Apfel“ versehen sind, auch als mit dem Tag „Frucht“ versehen betrachtet. Wenn also nach Inhalten gesucht wird, die mit dem Tag „Frucht“ versehen sind, werden auch Inhalte mit dem Tag „Frucht/Apfel“ gefunden.
Wenn die Tag-ID einen Doppelpunkt enthält, trennt der Doppelpunkt den Namespace vom Tag oder der Untertaxonomie, die dann mit normalen Schrägstrichen voneinander getrennt werden. Wenn in der Tag-ID kein Doppelpunkt vorkommt, ist der Standard-Namespace impliziert.
Der standardmäßige und einzige Speicherort von Tags ist unter /content/cq:tags.
Tags, die auf nicht vorhandene Pfade oder Pfade verweisen, die nicht auf einen cq:Tag-Knoten verweisen, werden als ungültig betrachtet und ignoriert.
Die folgende Tabelle zeigt einige Beispiel-Tag-IDs, ihre Elemente und wie die Tag-ID einen absoluten Pfad im Repository ergibt:
Die folgende Tabelle zeigt einige Beispiel-Tag-IDs, ihre Elemente und wie die Tag-ID einen absoluten Pfad im Repository ergibt:
Die folgende Tabelle zeigt einige Beispiel-Tag-IDs, ihre Elemente und wie die Tag-ID einen absoluten Pfad im Repository ergibt:
Tag-ID |
Namespace | Lokale ID | Container-Tag(s) | Leaf-Tag | Repository Absoluter Tag-Pfad |
dam:Frucht/Apfel/Braeburn | dam | Obst/Apfel/Braeburn | Obst, Apfel | Braeburn | /content/cq:tags/dam/fruit/apple/braeburn |
color/red | default | color/red | color | red | /content/cq:tags/default/color/red |
Himmel | default | Himmel | (keine) | Himmel | /content/cq:tags/default/sky |
dam: | dam | (keine) | (keine) | (keine, der Namensraum) | /content/cq:tags/dam |
/content/cq:tags/Kategorie/car | kategorie | car | car | car | /content/cq:tags/Kategorie/car |
Wenn das Tag den optionalen Titelstring enthält (jcr:title
) ist es möglich, den Titel zur Anzeige zu lokalisieren, indem die Eigenschaft jcr:title.<locale>
> hinzugefügt wird.
Weitere Informationen finden Sie unter
Tags bestehen als Knoten im Repository unter dem Stammknoten der Taxonomie. Sie erlauben oder verweigern Autoren und Websitebesuchern die Erstellung von Tags in einem jeweiligen Namespace, indem Sie im Repository entpsrechende ACLs festlegen.
Außerdem können Sie die Fähigkeit zur Anwendung von Tags auf bestimmte Inhalte steuern, indem Sie Leseberechtigungen für bestimmte Tags oder Namespaces einschränken.
Eine typische Vorgehensweise umfasst Folgendes:
Zulassen des Gruppen-/Rollenschreibzugriffs auf alle Namensraum (Hinzufügen/Ändern unter /content/cq:tags
). tag-administrators
Diese Gruppe enthält AEM standardmäßig.
Gewähren von Lesezugriff für Benutzer/Autoren auf alle Namespaces, die sie lesen können müssen (meist alle).
Benutzern/Autoren Schreibzugriff auf die Namensraum zu ermöglichen, in denen Tags von Benutzern/Autoren frei definierbar sein sollten (add_node unter /content/cq:tags/some_namespace
)
Damit Anwendungsentwickler Tagging an einen Inhaltstyp anhängen können, muss die Registrierung des Knotens (CND) das cq:Taggable
-Mixin oder das cq:OwnerTaggable
-Mixin enthalten.
Das Mixin cq:OwnerTaggable
, der von cq:Taggable
übernimmt, soll anzeigen, dass der Inhalt vom Besitzer/Autor klassifiziert werden kann. In AEM ist es nur ein Attribut des Knotens cq:PageContent
. Das cq:OwnerTaggable
-Mixin ist für das Tagging-Framework nicht erforderlich.
Es wird empfohlen, Tags nur auf dem Knoten der obersten Ebene eines aggregierten Inhaltselements (oder dessen jcr:content-Knoten) zu aktivieren. Beispiele dafür sind:
Seiten ( cq:Page
), bei denen die jcr:content
Node vom Typ cq:PageContent
ist, die das cq:Taggable
-Mixin enthält.
Assets ( cq:Asset
), wobei der jcr:content/metadata
-Knoten immer über das cq:Taggable
-Mixin verfügt.
Knotentypdefinitionen sind im Repository als CND-Dateien vorhanden. Die CND-Notation wird als Teil der JCR-Dokumentation hier definiert.
Die wichtigsten Definitionen für die Knotentypen in AEM sind wie folgt:
[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
Die Eigenschaft cq:tags
ist ein String-Array, das zum Speichern mindestens einer Tag-ID verwendet wird, wenn diese von Autoren oder Websitebesuchern auf Inhalte angewendet werden. Die Eigenschaft hat nur dann eine Bedeutung, wenn sie einem Knoten hinzugefügt wird, der mit dem Mixin cq:Taggable
definiert wird.
Um AEM Tagging-Funktion zu nutzen, sollten benutzerdefinierte Anwendungen keine anderen Tag-Eigenschaften als cq:tags
definieren.
Im Folgenden finden Sie eine Beschreibung der Auswirkungen, die im Repository auftreten, wenn Sie Tags mit der Tagging-Konsole verschieben oder zusammenführen:
Wenn ein Tag A verschoben oder in Tag B unter /content/cq:tags
zusammengeführt wird:
cq:movedTo
-Eigenschaft.cq:backlinks
-Eigenschaft.cq:movedTo
verweist auf Tag B.
Diese Eigenschaft bedeutet, dass Tag A verschoben oder in Tag B zusammengeführt wurde. Durch Verschieben von Tag B wird diese Eigenschaft entsprechend aktualisiert. Tag A ist somit ausgeblendet und wird nur im Repository behalten, um Tag-IDs in Inhaltsknoten aufzulösen, die auf Tag A verweisen. Der Garbage Collector für Tags entfernt Tags wie Tag A, sobald keine Inhaltsknoten mehr darauf verweisen.
Ein spezieller Wert für die cq:movedTo
-Eigenschaft ist nirvana
: wird angewendet, wenn das Tag gelöscht wird, aber nicht aus dem Repository entfernt werden kann, da es Untertags mit einem cq:movedTo
gibt, die beibehalten werden müssen.
Die cq:movedTo
-Eigenschaft wird dem verschobenen oder zusammengeführten Tag nur hinzugefügt, wenn eine der folgenden Bedingungen erfüllt ist:
cq:backlinks
speichert Verweise in die andere Richtung, d. h. sie enthält eine Liste aller Tags, die verschoben oder mit Tag B zusammengeführt wurden. Dies ist hauptsächlich erforderlich, um cq:movedTo
-Eigenschaften auf dem aktuellen Stand zu halten, wenn Tag B auch verschoben/zusammengeführt/gelöscht oder aktiviert wird. In diesem Fall müssen all seine backlinks-Tags ebenso aktiviert werden.
Die cq:backlinks
-Eigenschaft wird dem verschobenen oder zusammengeführten Tag nur hinzugefügt, wenn eine der folgenden Bedingungen erfüllt ist:
Das Lesen einer cq:tags
-Eigenschaft eines Inhaltsknotens umfasst die folgenden Auflösungen:
Wenn unter /content/cq:tags
keine Übereinstimmung vorhanden ist, wird kein Tag zurückgegeben.
Wenn das Tag eine cq:movedTo
-Eigenschaft aufweist, steht danach die referenzierte Tag-ID.
Dieser Schritt wird so lange wiederholt, wie das angehängte Tag eine cq:movedTo
-Eigenschaft aufweist.
Falls das angehängte Tag nicht über eine cq:movedTo
-Eigenschaft verfügt, wird das Tag gelesen.
Um eine Änderung zu veröffentlichen, wenn ein Tag verschoben oder zusammengeführt wurde, müssen der Knoten cq:Tag
und all seine Backlinks repliziert werden. Dies geschieht automatisch, wenn das Tag in der Tag-Verwaltungskonsole aktiviert wird.
Spätere Aktualisierungen der cq:tags
-Eigenschaft der Seite bereinigen automatisch die „alten“ Verweise. Dies wird ausgelöst, da die Auflösung eines verschobenen Tags über die API das Ziel-Tag zurückgibt und so die Ziel-Tag-ID bereitstellt.
Tags ab Experience Manager 6.4 werden unter /content/cq:tags
gespeichert, die zuvor unter /etc/tags
gespeichert wurden. In Szenarien, in denen Adobe Experience Manager von einer früheren Version aktualisiert wurde, sind die Tags jedoch immer noch unter dem alten Speicherort /etc/tags
vorhanden. Bei aktualisierten Systemen müssen Tags unter /content/cq:tags
migriert werden.
Auf der Seite "Seiteneigenschaften"der Tags wird empfohlen, Tag-ID zu verwenden (z. B. geometrixx-outdoors:activity/biking
), anstatt den Tag-Basispfad (z. B. /etc/tags/geometrixx-outdoors/activity/biking
) fest zu kodieren.
Zur Liste von Tags kann com.day.cq.tagging.servlets.TagListServlet
verwendet werden.
Es wird empfohlen, die Tag-Manager-API als Ressource zu verwenden.
Wenn die aktualisierte AEM TagManager-API unterstützt
Am Beginn der Komponente erkennt die TagManager-API, ob es sich um eine aktualisierte AEM handelt. Im aktualisierten System werden Tags unter /etc/tags
gespeichert.
Die TagManager-API wird dann im Abwärtskompatibilitätsmodus ausgeführt, d. h. die API verwendet /etc/tags
als Basispfad. Ist dies nicht der Fall, wird der neue Speicherort /content/cq:tags
verwendet.
Aktualisieren Sie den Tag-Speicherort.
Führen Sie nach der Migration von Tags an den neuen Speicherort das folgende Skript aus:
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-------------------------------------"
Das Skript ruft alle Tags ab, die im Wert der Eigenschaft cq:movedTo/cq:backLinks
/etc/tags
<a0/> enthalten. Anschließend durchläuft er den abgerufenen Ergebnissatz und löst die Eigenschaftswerte cq:movedTo
und cq:backlinks
auf /content/cq:tags
Pfade (sofern /etc/tags
im Wert erkannt wird).
Wenn eine aktualisierte AEM auf der klaasischen Benutzeroberfläche ausgeführt wird
Die klassische Benutzeroberfläche ist nicht mit Ausfallzeiten 0 kompatibel und unterstützt keinen neuen Tag-Basispfad. Wenn Sie die klassische Benutzeroberfläche verwenden möchten, muss /etc/tags
erstellt werden, gefolgt von cq-tagging
Komponenten-Neustart.
Bei aktualisierten AEM, die von der TagManager-API unterstützt werden und in der klassischen Benutzeroberfläche ausgeführt werden:
Nachdem Verweise auf den alten Tag-Basispfad /etc/tags
durch tagId oder den neuen Tag-Speicherort /content/cq:tags
ersetzt wurden, können Sie Tags in CRX an den neuen Speicherort /content/cq:tags
migrieren und anschließend einen Komponenten-Neustart durchführen.
Führen Sie nach der Migration von Tags an den neuen Speicherort das oben genannte Skript aus.