コンテンツにタグ付けし、AEM タグ付けインフラストラクチャを利用するには:
タグ付けされたコンテンツノードのノードタイプには、cq:Taggable
mixin が含まれている必要があります。
タグの宣言は、リポジトリーにおける cq:Tag.
タイプのノードにキャプチャされます。
タグは、単純な単語(sky など)にしたり、階層分類(包括的な fruit と具体的な apple の両方を意味する fruit/apple など)を表したりすることができます。
タグは一意のタグ ID によって識別されます。
タグには、タイトル、ローカライズされたタイトル、説明など、任意のメタ情報があります。タイトルは、TagIDが存在する場合は、TagIDではなくユーザーインターフェイスに表示されます。
タグ付けフレームワークでは、作成者やサイト訪問者に、特定の事前定義されたタグだけを使用するよう制限を設けることもできます。
ノードタイプはcq:Tag
ノード名はTagID
オプションのjcr:title
プロパティ(UIに表示するタイトル)
オプションのjcr:description
プロパティ
子ノードが含まれている場合、コンテナタグと呼ばれます。
分類のルートノードと呼ばれる基本パスの下のリポジトリに保存されます。
タグ ID は、リポジトリ内のタグノードに解決されるパスを識別します。
通常、TagIDは、名前空間で始まる略称TagIDです。または、分類ルートノードから始まる絶対TagIDにすることもできます。
コンテンツにタグ付けするときに、コンテンツがまだ存在しない場合は、cq:tags
プロパティがコンテンツノードに追加され、タグ ID がこのプロパティの String 配列値に追加されます。
タグ ID は、名前空間とそれに続くローカルタグ ID で構成されます。コンテナタグにはサブタグがあり、これは分類における階層順序を表します。サブタグは、ローカルのTagIDと同じタグを参照するために使用できます。 例えば、コンテンツがサブタグを含むコンテナタグ(「fruit/apple」や「fruit/banana」など)であっても、コンテンツに「fruit」とタグ付けすることができます。
分類のルートノードは、リポジトリー内にあるすべてのタグの基本パスです。分類のルートノードは、 cq :Tag
タイプのノードにすることができません。
AEM の基本パスは /content/ cq :tags
であり、ルートノードのタイプは cq :Folder
です。
名前空間を使用するとグループ化をおこなうことができます。最も一般的な使用例は、(Web)サイトごと(公開、内部、ポータルなど)に名前空間を持つ場合、または大規模なアプリケーションごと(WCM、アセット、コミュニティなど)に名前空間を持つ場合ですが、他の様々なニーズに対しても使用できます。 名前空間は、現在のコンテンツに適用されるタグのサブセット(特定の名前空間のタグなど)のみを表示するためにユーザーインターフェイスで使用されます。
タグの名前空間は、分類サブツリーの最初のレベルです。これは、分類のルートノードの直下のノードです。の直下のノードです。名前空間は cq:Tag
タイプのノードで、その親は cq:Tag
ノードタイプではありません。
すべてのタグには名前空間があります。名前空間を指定しない場合、タグはデフォルトの名前空間(TagID default
)に割り当てられます(TitleはStandard Tags),
、/content/cq:tags/default.
)
コンテナタグは、任意の数およびタイプの子ノードを含む、cq:Tag
タイプのノードです。これにより、カスタムメタデータを使用してタグモデルを強化できます。
さらに、コンテナタグ(またはスーパータグ)は分類において、すべてのサブタグの小計としての機能を果たします。例えば fruit/apple でタグ付けされたコンテンツは、fruit でタグ付けされたとも見なされます。つまり、fruit でタグ付けされたコンテンツを検索すると、fruit/apple でタグ付けされたコンテンツも検索されます。
タグ ID にコロン「:」が含まれている場合、そのコロンによってタグやサブ分類から名前空間が区別され、その後、タグやサブ分類は通常のスラッシュ「/」で区別されます。タグ ID にコロンが含まれていない場合は、デフォルトの名前空間が暗示されます。
タグの標準的で唯一の場所は/content/cq:tagsの下です。
cq:Tagノードを指していない、既存でないパスまたはパスを参照するタグは、無効と見なされ、無視されます。
次の表に、タグ ID の例とその要素、リポジトリでそのタグ ID がどのように絶対パスに解決されるかを示します。
次の表に、タグ ID の例とその要素、リポジトリでそのタグ ID がどのように絶対パスに解決されるかを示します。
次の表に、タグ ID の例とその要素、リポジトリでそのタグ ID がどのように絶対パスに解決されるかを示します。
タグ ID |
名前空間 | ローカル ID | コンテナタグ | リーフタグ | Repository 絶対タグパス |
dam:fruit/apple/braeburn | dam | fruit/apple/braeburn | 果物、リンゴ | ブレーバーン | /content:tags/dam/fruit/apple/braeburn |
color/red | default | color/red | カラー | red | /content/cq:tags/default/color/red |
sky | default | sky | (なし) | sky | /content/cq:tags/default/sky |
dam: | ダム | (なし) | (なし) | (なし、名前空間) | /content/cq:tags/dam |
/content/cq:tags/カテゴリ/car | カテゴリ | 車 | 車 | 車 | /content/cq:tags/カテゴリ/car |
タグにオプションのタイトル文字列(jcr:title
)が含まれる場合は、jcr:title.<locale>
プロパティを追加して、表示するタイトルをローカライズできます。
詳しくは、以下を参照してください。
タグは、リポジトリ内で分類のルートノードの下にノードとして存在します。特定の名前空間で作成者やサイト訪問者がタグを作成することを許可または拒否するには、リポジトリで適切なACLを設定します。
また、特定のタグまたは名前空間に対する読み取り権限を拒否することで、特定のコンテンツへのタグの適用を制御できます。
一般的な方法には次のものがあります。
すべての名前空間への書き込みアクセス(/content/cq:tags
下への add/modify)をtag-administrators
グループ/役割に許可する。このグループは、追加設定なしで使用できる AEM に付属しています。
読み取り可能にする必要があるすべての名前空間への読み取りアクセスをユーザー/作成者に許可する。
タグを自由に定義できる名前空間(/content/cq:tags/some_namespace
の下のadd_node)への書き込みアクセスを許可する
アプリケーション開発者がコンテンツタイプにタグ付けを付加するには、ノードの登録(CND)に cq:Taggable
Mixin または cq:OwnerTaggable
Mixin を含める必要があります。
cq:OwnerTaggable
Mixin は cq:Taggable
から継承されており、その目的は、所有者または作成者がコンテンツを分類できることを示すことです。AEM では、cq:PageContent
ノードの属性にすぎません。cq:OwnerTaggable
Mixin は、タグ付けフレームワークには必要ありません。
集約されたコンテンツアイテムの最上位ノード(またはその jcr:content ノード)では、タグの有効化だけをおこなうことをお勧めします。以下に例を示します。
jcr:content
ノードのタイプがcq:PageContent
で、cq:Taggable
ミックスインが含まれているページ(cq:Page
)。
アセット(cq:Asset
)。jcr:content/metadata
ノードには常にcq:Taggable
ミックスインがあります。
ノードタイプの定義は、リポジトリー内に CND ファイルとして存在します。CND表記は、JCRドキュメントここの一部として定義されています。
AEM に含まれるノードタイプの基本的な定義は、次のようになります。
[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
cq:tags
プロパティは、作成者またはサイト訪問者によってコンテンツに 1 つ以上のタグ ID が割り当てられたときにその ID を格納するための文字列配列です。このプロパティは、cq:Taggable
Mixin で定義されているノードに追加した場合にのみ意味があります。
AEM のタグ付け機能を使用するには、カスタムで開発されたアプリケーションで cq:tags
以外のタグプロパティを定義しないでください。
次に、タグ付けコンソールを使用してタグの移動または統合を実行した場合のリポジトリ内での影響について説明します。
タグAを/content/cq:tags
の下のタグBに移動または結合する場合:
cq:movedTo
プロパティを取得します。cq:backlinks
プロパティが取得されます。cq:movedTo
はタグ B を指します。
このプロパティは、タグ A がタグ B に移動または結合されたことを意味します。タグ B を移動すると、それに応じてこのプロパティが更新されます。タグ A は非表示になり、タグ A を示すコンテンツノード内のタグ ID を解決するリポジトリに保持されるだけになります。タグガベージコレクターは、タグ A のように、コンテンツノードで指定されなくなったタグを削除します。
cq:movedTo
プロパティの特別な値はnirvana
です。タグが削除された場合に適用されますが、リポジトリから削除することはできません。これは、保持する必要があるcq:movedTo
を持つサブタグが存在するためです。
cq:movedTo
プロパティは、次のいずれかの条件を満たす場合にのみ、移動または結合されたタグに追加されます。
cq:backlinks
は、他のリスト(タグBとの間で移動または結合されたすべてのタグのを保持する)。これは、タグBの移動/結合/削除時やタグBのアクティブ化時に、 cq:movedTo
プロパティを最新の状態に維持する必要が大きい場合です。
cq:backlinks
プロパティは、次のいずれかの条件を満たす場合にのみ、移動または結合されたタグに追加されます。
コンテンツノードの cq:tags
プロパティを読み取ると、以下のように解決されます。
/content/cq:tags
下で一致するものが見つからない場合、タグは返されません。
タグに cq:movedTo
プロパティが設定されている場合は、参照先のタグ ID が使用されます。
これは、その次のタグに cq:movedTo
プロパティがある限り繰り返されます。
次のタグに cq:movedTo
プロパティがない場合は、そのタグが読み取られます。
タグが移動またはマージされたときにその変更を発行するには、cq:Tag
ノードとそのすべてのバックリンクを複製する必要があります。この処理は、タグ管理コンソールでタグがアクティベートされたときに自動的に実行されます。
後でページの cq:tags
プロパティに対して更新がおこなわれると、「以前の」参照が自動的にクリーンアップされます。移動したタグを API で解決すると移動先のタグが戻され、移動先のタグ ID が提供されることから、この処理がトリガーされます。
Experience Manager6.4以降のタグは/content/cq:tags
に格納され、/etc/tags
に格納されていました。 ただし、Adobe Experience Managerが以前のバージョンからアップグレードされた場合、タグは古い場所/etc/tags
に残っています。 アップグレードしたシステムのタグは、/content/cq:tags
の下に移行する必要があります。
タグページのページプロパティでは、タグベースパス(/etc/tags/geometrixx-outdoors/activity/biking
など)をハードコーディングする代わりに、タグID(例:geometrixx-outdoors:activity/biking
)を使用することをお勧めします。
リストタグにはcom.day.cq.tagging.servlets.TagListServlet
を使用できます。
タグマネージャーAPIをリソースとして使用することをお勧めします。
アップグレードしたAEMインスタンスがTagManager APIをサポートする場合
コンポーネントの開始時に、TagManager APIはアップグレードされたAEMインスタンスであるかどうかを検出します。 アップグレードしたシステムでは、タグは/etc/tags
の下に保存されます。
次に、TagManager APIは下位互換モードで実行されます。つまり、APIは/etc/tags
をベースパスとして使用します。 そうでない場合は、新しい場所/content/cq:tags
が使用されます。
タグの場所を更新します。
タグを新しい場所に移行した後、次のスクリプトを実行します。
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-------------------------------------"
スクリプトは、cq:movedTo/cq:backLinks
プロパティの値に/etc/tags
が含まれるすべてのタグを取得します。 次に、取得した結果セットを繰り返し処理し、cq:movedTo
とcq:backlinks
のプロパティ値を/content/cq:tags
パスに解決します(値に/etc/tags
が検出された場合)。
アップグレードしたAEMインスタンスがClasic UIで実行される場合
クラシックUIは、ダウンタイムゼロの互換性がなく、新しいタグ基本パスをサポートしていません。 /etc/tags
よりも古いUIを使用する場合は、cq-tagging
コンポーネントを再起動して作成する必要があります。
アップグレードしたAEMインスタンスがTagManager APIでサポートされ、クラシックUIで実行される場合:
古いタグベースパス/etc/tags
への参照をtagIdまたは新しいタグの場所/content/cq:tags
を使用して置き換えると、CRXの新しい場所/content/cq:tags
にタグを移行し、その後でコンポーネントを再起動できます。
タグを新しい場所に移行した後、上記のスクリプトを実行します。