Experience League

Experience Cloud

Document Cloud

AEM コンポーネント - 基本

新しいコンポーネントの開発にとりかかる際は、その構造と設定の基本を理解する必要があります。

これには、標準的なセオリーを学び、標準 AEM インスタンスでのコンポーネントの実装を幅広く知ることが含まれます。AEM は新しい標準のタッチ操作対応 UI に変更されましたが、引き続きクラシック UI をサポートしているので、この後者のアプローチは少し複雑です。

概要

この節では、独自コンポーネントの開発時に知っておくべき詳細の導入段階として、基本的な概念と注意点について説明します。

計画

実際にコンポーネントを設定またはコーディングする前に、次のように尋ねる必要があります。

そもそも新しいコンポーネントで何をするか
- 明確な仕様は、開発、テスト、引継ぎのあらゆる段階で役立ちます。
  
  詳細は時間と共に変化する可能性がありますが、仕様は更新可能です（ただし、変更箇所を記録しておく必要があります）。
コンポーネントを一から作成する必要があるか、基本部分を既存のコンポーネントから継承できるか
- 一から作成する必要があるとは限りません。
- AEMには、上書き、オーバーレイ、Sling Resource Margeなど、別のコンポーネント定義の詳細を継承および拡張するメカニズムがいくつか用意されています。
コンポーネントのコンテンツを選択または操作するためのロジックが必要か
- ロジックは、ユーザーインターフェイス層から分離しておく必要があります。HTL はこれに対応した設計になっています。
コンポーネントを CSS で書式設定する必要があるか
- CSS による書式設定は、コンポーネント定義から分離しておく必要があります。外部の CSS ファイルを通じて HTML 要素を変更できるように、HTML 要素の命名規約を定義してください。
考慮すべきセキュリティ要素は何か
- 詳しくは、セキュリティチェックリスト - 開発のベストプラクティスを参照してください。

タッチ操作対応 UI とクラシック UI の違い

コンポーネントの開発について本格的な検討を始める前に、作成者がどちらの UI を使用するかを知っておく必要があります。

タッチ操作対応 UI
AEM 5.6.0でプレビューとして導入され、6.xで拡張された標準ユーザーインターフェイス。これは、 Coral UIと Granite UIの基盤テクノロジーを使用した、Adobe Marketing Cloudの統合ユーザーエクスペリエンスに基づいています。
クラシック UI CQ 5.1 で導入された、ExtJS テクノロジーに基づくユーザーインターフェイスです。

詳しくは、UI インターフェイスに関するお客様向け推奨事項を参照してください。

タッチ操作対応 UI、クラシック UI または両方をサポートするようにコンポーネントを実装できます。標準インスタンスを見ると、最初にクラシックUI、タッチ対応UI、またはその両方用にデザインされた、標準搭載のコンポーネントも表示されます。

このため、このページでは両 UI の基本と識別方法について説明します。

メモ

Adobeでは、最新のテクノロジーを活用するために、タッチ対応UIの活用を推奨します。 AEM Modernization Toolscanを使用すると、移行が容易になります。

コンテンツのロジックとマークアップのレンダリング

マークアップおよびレンダリングをおこなうコードと、コンポーネントのコンテンツ選択に関するロジックを制御するコードは、分離しておくことをお勧めします。

この方法をサポートするテンプレート言語が HTL です。HTL では、基盤となるビジネスロジックを定義するときにのみプログラミング言語を使用します。この（オプションの）ロジックは、特定のコマンドで HTL から呼び出されます。この仕組みでは、特定のビュー用に呼び出されるコードに焦点を当てることができるので、必要に応じて、同じコンポーネントの様々なビュー用のロジックを定義できます。

HTL と JSP

HTLは、AEM 6.0で導入されたHTMLテンプレート言語です。

独自コンポーネントの開発時に HTL と JSP（Java Server Pages）のどちらを使用すべきかという質問への回答は明快です。現在では、HTL が AEM の推奨スクリプティング言語とされています。

HTL と JSP はどちらも、クラシック UI とタッチ操作対応 UI の両方のコンポーネントの開発に使用できます。HTL はタッチ操作対応 UI 専用で JSP はクラシック UI 用だと想定する傾向があるかもしれませんが、これは時期に起因する誤解です。タッチ操作対応 UI と HTL は、ほぼ同時期に AEM に組み込まれました。HTL は現在推奨される言語なので、新しいコンポーネントに使用されており、このため、タッチ操作対応 UI に使用される傾向があります。

メモ

例外は、ダイアログで使用される Granite UI 基盤のフォームフィールドです。このフィールドには、引き続き JSP を使用する必要があります。

独自コンポーネントの開発

UI の種類に応じた独自コンポーネントを作成するには、（このページを読んでから）以下を参照してください。

既存のコンポーネントをコピーし、必要な変更をおこなうことが、開発を始めるうえで最も簡単な方法です。独自のコンポーネントを作成し、それを段落システムに追加する方法については、以下を参照してください。

コンポーネント開発（主にタッチ操作対応 UI）

パブリッシュインスタンスへのコンポーネントの移動

コンテンツをレンダリングするコンポーネントは、コンテンツと同じ AEM インスタンスにデプロイする必要があります。したがって、オーサーインスタンス上でページをオーサリングおよびレンダリングするために使用するすべてのコンポーネントを、パブリッシュインスタンスにデプロイする必要があります。デプロイすると、コンポーネントを使用して、アクティブ化されたページをレンダリングできるようになります。

コンポーネントをパブリッシュインスタンスに移動するには、次のツールを使用します。

Package Managerを使用してコンポーネントをパッケージに追加し、別のAEMインスタンスに移動します。
コンポーネントをレプリケートするには、「ツリーをアクティベート」レプリケーションツールを使用します。

メモ

これらの仕組みを利用して、開発インスタンスからテストインスタンスなど、インスタンス間でコンポーネントを移行することもできます。

最初から認識するコンポーネント

ページ:
- AEMにはページコンポーネント(cq:Page)があります。
- このコンポーネントは、コンテンツ管理にとって重要なリソースです。
  - ページコンポーネントは、Web サイトのコンテンツを保持する Web ページに対応しています。
段落システム：
- 段落システムは、Web サイトの重要な構成要素であり、段落のリストを管理します。実際のコンテンツを格納する個々のコンポーネントを保持し、構造化するために使用されます。
- 段落システム内で、段落を作成、移動、コピーおよび削除できます。
- 特定の段落システム内で使用可能にするコンポーネントを選択することもできます。
- 標準インスタンス内で使用できる様々な段落システムがあります（例：parsys, [responsivegrid](/docs/experience-manager-64/sites-authoring/responsive-layout.md)）。

構造

AEM コンポーネントの構造は強力で、柔軟性があります。主な考慮事項は次のとおりです。

リソースタイプ
コンポーネント定義
コンポーネントのプロパティおよび子ノード
ダイアログ
デザインダイアログ
使用可能なコンポーネント
コンポーネントおよびコンポーネントによって作成されるコンテンツ

リソースタイプ

構造の重要な構成要素となるのが、リソースタイプです。

コンテンツの構造は意図を宣言します。
リソースタイプはその意図を実装します。

このような抽象化をすることで、時間の経過と共にルックアンドフィールが変化しても、意図が変わることはありません。

コンポーネント定義

コンポーネントの基本

コンポーネントの定義は次のように分解できます。

AEM コンポーネントは、Sling に基づいています。
AEM コンポーネントは、（通常は）次の場所に配置されます。
- HTL: /libs/wcm/foundation/components
- JSP：/libs/foundation/components
プロジェクトまたはサイトに固有のコンポーネントは、（通常は）次の場所に配置されます。
- /apps/<myApp>/components
AEM の標準コンポーネントは、cq:Component として定義され、次の主要な構成要素を持ちます。
- jcrプロパティ：
  
  jcrプロパティのリストこれらは変数であり、一部はオプションですが、コンポーネントノードの基本構造、そのプロパティとサブノードはcq:Component定義によって定義されます
- リソース:
  
  コンポーネントで使用される静的要素を定義します。
- スクリプト:
コンポーネントの結果のインスタンスの動作を実装するために使用されます。
ルートノード：
- <mycomponent> (cq:Component) — コンポーネントの階層ノード。
重要なプロパティ：
- jcr:title - コンポーネントのタイトル。コンポーネントブラウザーまたはサイドキック内のコンポーネントリストに示すときのラベルとして使用されたりします。
- jcr:description - コンポーネントの説明。コンポーネントブラウザーまたはサイドキック内でマウスを上に置くと表示されるヒントとして使用できます。
- クラシック UI：
  - icon.png — このコンポーネントのアイコン。
  - thumbnail.png - このコンポーネントを段落システム内にリストする場合に表示される画像。
- タッチ UI
  - 詳しくは、タッチ UI のコンポーネントアイコンの節を参照してください。
重要な子ノード：
- cq:editConfig (cq:EditConfig) — コンポーネントの編集プロパティを定義し、コンポーネントをコンポーネントブラウザーまたはサイドキックに表示できるようにします。
  
  注意：コンポーネントにダイアログがある場合は、cq:editConfig が存在しなくても、コンポーネントは自動的にコンポーネントブラウザーまたはサイドキックに表示されます。
- cq:childEditConfig (cq:EditConfig) — 独自のコンポーネントを定義しない子コンポーネントの作成者UI要素を制御し cq:editConfigます。
- タッチ操作対応 UI：
  - cq:dialog ( nt:unstructured) — このコンポーネントのダイアログ。ユーザーがコンポーネントを設定したり、コンテンツを編集したりできるインターフェイスを定義します。
  - cq:design_dialog ( nt:unstructured) — このコンポーネントのデザイン編集
- クラシック UI：
  - dialog ( cq:Dialog) — このコンポーネントのダイアログ。ユーザーがコンポーネントを設定したり、コンテンツを編集したりできるインターフェイスを定義します。
  - design_dialog ( cq:Dialog) — このコンポーネントのデザイン編集。

タッチ UI のコンポーネントアイコン

コンポーネントのアイコンまたは省略形は、開発者がコンポーネントを作成する際に、コンポーネントのJCRプロパティを介して定義されます。これらのプロパティは、次の順番で評価され、最初に見つかった有効なプロパティが使用されます。

cq:icon — コンポーネントブラウザに表示する Coral UI ライブラリ内の標準アイコンを示す文字列プロパティ。
- Coral アイコンの HTML 属性の値を使用します。
abbreviation — コンポーネントブラウザのコンポーネント名の省略形をカスタマイズする文字列プロパティ
- 省略形は最大2 文字までにする必要があります。
- 空の文字列を指定すると、jcr:titleプロパティの最初の2文字から省略形が作成されます。
  - 例えば、「Image」の場合は「Im」になります。
  - ローカライズされたタイトルが省略形の作成に使用されます。
- 省略形は、コンポーネントに abbreviation_commentI18n プロパティがある場合にのみ翻訳されます。これは、翻訳ヒントとして使用されます。
cq:icon.png または cq:icon.svg — コンポーネントのアイコン（コンポーネントブラウザに表示）
- 20 x 20 pixel は、標準的なコンポーネントのアイコンのサイズです。
  - 大きいアイコンはクライアント側で縮小されます。
- レコメンデーションカラーはrgb(112, 112, 112) > #707070です。
- 標準的なコンポーネントアイコンの背景は、透明です。
- .pngファイルと.svgファイルのみがサポートされています。
- Eclipseプラグインを介してファイルシステムからインポートする場合、ファイル名は_cq_icon.pngや_cq_icon.svgのようにエスケープする必要があります。
- .png 両者が存在す .svg る場合に先例となる

上記のプロパティ(cq:icon、abbreviation、cq:icon.png、cq:icon.svg)がコンポーネントに見つからない場合：

システムは、sling:resourceSuperType プロパティに続くスーパーコンポーネント上の同じプロパティを検索します。
スーパーコンポーネントレベルで省略形が見つからない場合や空の省略形が見つかった場合は、現在のコンポーネントのjcr:titleプロパティの最初の文字から省略形が作成されます。

スーパーコンポーネントからアイコンの継承をキャンセルするために、コンポーネントで空の abbreviation プロパティを設定すると、デフォルトの動作に戻ります。

コンポーネントコンソールには、特定のコンポーネントのアイコンの定義方法が表示されます。

SVG アイコンの例

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "https://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" x="0px" y="0px"
     width="20px" height="20px" viewBox="0 0 20 20" enable-background="new 0 0 20 20" xml:space="preserve">
    <ellipse cx="5" cy="5" rx="3" ry="3" fill="#707070"/>
    <ellipse cx="15" cy="5" rx="4" ry="4" fill="#707070"/>
    <ellipse cx="5" cy="15" rx="5" ry="5" fill="#707070"/>
    <ellipse cx="15" cy="15" rx="4" ry="4" fill="#707070"/>
</svg>

コンポーネントのプロパティおよび子ノード

コンポーネントの定義に必要なノードまたはプロパティの多くは、両方の UI に共通です。コンポーネントがどちらの環境でも機能できるよう、相違点の独立性は確保されています。

コンポーネントはタイプ cq:Component のノードで、次のプロパティと子ノードがあります。

名前	種類	説明
.	`cq:Component`	現在のコンポーネント。コンポーネントはノードタイプ`cq:Component`. です
`componentGroup`	`String`	コンポーネントブラウザー（タッチ操作対応 UI）またはサイドキック（クラシック UI）でコンポーネントを選択できるグループ。の値 `.hidden` は、実際の段落システムなど、UIから選択できないコンポーネントに使用されます。
`cq:isContainer`	`Boolean`	コンポーネントがコンテナコンポーネントかどうか、したがって段落システムなど他のコンポーネントを格納できるかどうかを示します。

`cq:dialog`	`nt:unstructured`	タッチ操作対応 UI 用の編集ダイアログの定義。
`dialog`	`cq:Dialog`	クラシック UI 用の編集ダイアログの定義。
`cq:design_dialog`	`nt:unstructured`	タッチ操作対応 UI 用のデザインダイアログの定義。
`design_dialog`	`cq:Dialog`	クラシック UI 用のデザインダイアログの定義。
`dialogPath`	`String`	コンポーネントにダイアログノードがない場合のダイアログへのパス。

`cq:cellName`	`String`	設定した場合、このプロパティはセル ID として取得されます。詳しくは、ナレッジベースの記事「How are Design Cell IDs built」を参照してください。
`cq:childEditConfig`	`cq:EditConfig`	コンポーネントがコンテナの場合（例えば、段落システムの場合）は、これにより子ノードの設定を編集できます。
`cq:editConfig`	`cq:EditConfig`	コンポーネントの編集設定。
`cq:htmlTag`	`nt:unstructured`	対象を囲んでいる html タグに追加されたその他のタグ属性を返します。自動生成された div に属性を追加できます。
`cq:noDecoration`	`Boolean`	true の場合、コンポーネントは、自動生成された div クラスと css クラスでレンダリングされません。
`cq:template`	`nt:unstructured`	このプロパティがあると、コンポーネントがコンポーネントブラウザーまたはサイドキックから追加された場合に、このノードは、コンテンツテンプレートとして使用されます。
`cq:templatePath`	`String`	コンポーネントブラウザーまたはサイドキックからコンポーネントを追加するときにコンテンツテンプレートとして使用されるノードのパス。これは、コンポーネントノードの相対パスではなく、絶対パスにする必要があります。他の場所で既に使用可能なコンテンツを再利用しないのであれば不要であり、`cq:template` で十分です（下記参照）。
`jcr:created`	`Date`	コンポーネントの作成日。
`jcr:description`	`String`	コンポーネントの説明。
`jcr:title`	`String`	コンポーネントのタイトル。
`sling:resourceSuperType`	`String`	設定した場合、コンポーネントの継承元がこのコンポーネントになります。
`virtual`	`sling:Folder`	仮想コンポーネントを作成できます。例を見るには、次の連絡先コンポーネントを参照してください。 `/libs/foundation/components/profile/form/contact`
`<breadcrumb.jsp>`	`nt:file`	スクリプトファイル。
`icon.png`	`nt:file`	コンポーネントのアイコンがサイドキックのタイトルの隣に表示されます。
`thumbnail.png`	`nt:file`	サイドキックからコンポーネントをドラッグしている間に表示されるオプションのサムネール。

テキストコンポーネント（どちらかのバージョン）を見ると、次の要素が表示されます。

HTL ( /libs/wcm/foundation/components/text)
JSP ( /libs/foundation/components/text)

特に重要なプロパティを次に示します。

jcr:title - コンポーネントのタイトル。コンポーネントブラウザーまたはサイドキック内のコンポーネントリストに表示されたりするコンポーネントの識別に使用できます。
jcr:description - コンポーネントの説明。サイドキック内のコンポーネントリストでマウスオーバーヒントとして使用できます。
sling:resourceSuperType - （定義のオーバーライドによる）コンポーネントの拡張時に、継承パスを示します。

特に重要な子ノードを次に示します。

cq:editConfig ( cq:EditConfig) — 視覚的な外観を制御します。例えば、バーやウィジェットの外観を定義したり、カスタマイズしたコントロールを追加したりできます
cq:childEditConfig ( cq:EditConfig) — 独自の定義を持たない子コンポーネントの視覚的な外観を制御します。
タッチ操作対応 UI：
- cq:dialog ( nt:unstructured) — このコンポーネントのコンテンツを編集するためのダイアログを定義します。
- cq:design_dialog ( nt:unstructured) — このコンポーネントのデザイン編集オプションを指定します。
クラシック UI：
- dialog ( cq:Dialog) — このコンポーネントのコンテンツを編集するためのダイアログを定義します（クラシックUIに固有）。
- design_dialog ( cq:Dialog) — このコンポーネントのデザイン編集オプションを指定します。
- icon.png - サイドキック内のコンポーネントのアイコンとして使用されるグラフィックファイル
- thumbnail.png - サイドキックからコンポーネントをドラッグしている間、そのサムネールとして使用されるグラフィックファイル

ダイアログ

ダイアログは、コンポーネントの主要な要素の一つです。作成者がコンポーネントを設定し、必要情報を提供するためのインターフェイスをダイアログが備えているからです。

コンポーネントの複雑さに応じて、ダイアログには 1 つ以上のタブが必要です。これは、ダイアログを簡潔にし、必要情報フィールドを分類するためです。

ダイアログの定義は UI に固有です。

メモ

互換性を保つために、タッチ操作対応 UI 用のダイアログが定義されていない場合、タッチ操作対応 UI でクラシック UI ダイアログの定義を使用できます。
クラシック UI 用のダイアログのみが定義されているコンポーネントを拡張または変換するときのために、ダイアログ変換ツールも用意されています。

タッチ操作対応 UI
- cq:dialog ( nt:unstructured) nodes:
  - このコンポーネントのコンテンツ編集に使用するダイアログを定義します。
  - タッチ操作対応 UI 専用です。
  - Granite UI コンポーネントを使用して定義されます。
  - 標準のSlingコンテンツ構造としてsling:resourceTypeプロパティを持つ
  - helpPath プロパティを指定できます。このプロパティでは、ヘルプアイコン（「?」アイコン)が選択されている。
    - 既成のコンポーネントでは多くの場合、ドキュメントのページが参照されます。
    - helpPath が指定されていない場合、デフォルトのURL（ドキュメントの概要ページ）が表示されます。
ダイアログ内で、個々のフィールドは次のように定義されます。
クラシック UI
- dialog ( cq:Dialog) nodes
  - このコンポーネントのコンテンツ編集に使用するダイアログを定義します。
  - クラシック UI 専用です。
  - ExtJS ウィジェットを使用して定義されます。
  - ExtJS を参照する xtype プロパティを持ちます。
  - helpPath プロパティを指定できます。このプロパティでは、ヘルプボタンが選択された場合に表示される状況依存型ヘルプリソースを定義します（絶対パスまたは相対パス）。
    - 既成のコンポーネントでは多くの場合、ドキュメントのページが参照されます。
    - helpPath が指定されていない場合、デフォルトのURL（ドキュメントの概要ページ）が表示されます。
ダイアログ内で、個々のフィールドは次のように定義されます。

クラシックダイアログボックス内では、次の操作を行います。
- ダイアログを cq:Dialog として作成できます。これはテキストコンポーネント内のダイアログと同様に、タブを 1 つだけ含みます。複数のタブが必要な場合は、textimage コンポーネントと同様に、ダイアログを cq:TabPanel として定義できます。
- cq:WidgetCollection ( items)は、入力フィールド( cq:Widget)またはその他のタブ( cq:Widget)のベースを提供するために使用します。この階層は、拡張することが可能です。

デザインダイアログ

デザインダイアログは、コンテンツの編集や設定に使用されるダイアログによく似ていますが、そのコンポーネントのデザインの詳細を作成者が設定できるようにするインターフェイスを提供します。

デザインダイアログはデザインモードで使用可能ですが、必ずしもすべてのコンポーネントに必要なわけではありません。例えば、タイトルコンポーネントと画像コンポーネントにはどちらもデザインダイアログがありますが、テキストコンポーネントにはありません。

段落システム（parsys など）用のデザインダイアログは特殊なケースで、ユーザーはこのデザインダイアログを使用して、特定の他のコンポーネントをページ上で（コンポーネントブラウザーまたはサイドキックから）選択することができます。

コンポーネントを段落システムに追加

コンポーネントを定義した上で、使用可能にする必要があります。コンポーネントを段落システムで使用可能にするには、次のどちらかの方法を実行します。

ページに対してデザインモードを開き、必要なコンポーネントを有効にします。
必要なコンポーネントを次の場所にあるテンプレート定義の components プロパティに追加します。

/etc/designs/<*yourProject*>/jcr:content/<*yourTemplate*>/par

例：

/etc/designs/geometrixx/jcr:content/contentpage/par

コンポーネントおよびコンポーネントによって作成されるコンテンツ

ページ上のタイトルコンポーネントのインスタンスを作成し、設定する場合：<content-path>/Prototype.html

タッチ操作対応 UI
クラシック UI

ここで、リポジトリ内に作成されたコンテンツの構造を確認できます。

screen_shot_2012-02-13at61405pm

特に、タイトルコンポーネントの実際のテキストに着目した場合：

（両方の UI の）定義にプロパティ name= ./jcr:title
- /libs/foundation/components/title/cq:dialog/content/items/column/items/title
- /libs/foundation/components/title/dialog/items/title
この定義によって、コンテンツ内に作成者のコンテンツを保持する jcr:title というプロパティが生成されます。

定義されるプロパティは、個々の定義によって異なります。上記と比べて複雑なプロパティの場合もありますが、なお同じ基本原則に従っています。

コンポーネントの階層および継承

AEM 内のコンポーネントは、次の 3 種類の階層で表現されます。

リソースタイプの階層

これは、sling:resourceSuperTypeプロパティを使用してコンポーネントを拡張するために使用されます。これにより、コンポーネントの継承ができるようになります。例えば、テキストコンポーネントは標準コンポーネントから様々な属性を継承します。
- スクリプト（Sling によって解決）
- ダイアログ
- 説明（サムネール画像、アイコンなどを含む）
コンテナの階層

子コンポーネントに設定を適用するために使用されます。parsys シナリオで最もよく使用されています。

例えば、編集バーのボタン、コントロールセットのレイアウト（編集バー、ロールオーバー）、ダイアログのレイアウト（インライン、浮動）の設定を親コンポーネントで定義して、子コンポーネントに適用できます。

cq:editConfigとcq:childEditConfigの設定（編集機能に関連）が反映されます。
階層を含む

これは、インクルードのシーケンスによって実行時に課されます。

この階層は、デザイナーによって使用され、レンダリングの様々なデザイン側面、特にレイアウト情報、CSS 情報、parsys で使用可能なコンポーネントの基礎として機能します。

編集動作

この節では、コンポーネントの編集動作の設定方法について説明します。コンポーネントに対して使用可能なアクションなどの属性、インプレースエディターの特性、コンポーネントに対するイベントに関連するリスナーについても説明します。

固有の相違点は多少ありますが、設定はタッチ操作対応 UI とクラシック UI の両方に共通です。

コンポーネントの編集動作を設定するには、タイプ cq:editConfig の cq:EditConfig ノードをコンポーネントノード（タイプ cq:Component）の下に追加し、特定のプロパティと子ノードを追加します。使用可能なプロパティと子ノードを次に示します。

cq:editConfig ノードのプロパティ:
- cq:actions ( String array):コンポーネントに対して実行できるアクションを定義します。
- cq:layout ( String)::クラシックUIでのコンポーネントの編集方法を定義します。
- cq:dialogMode ( String):クラシックUIでコンポーネントダイアログを開く方法を定義します
  - タッチ操作対応 UI のダイアログは、デスクトップモードでは常に浮動し、モバイルでは自動的に全画面表示として開きます。
- cq:emptyText ( String):視覚的なコンテンツがない場合に表示するテキストを定義します。
- cq:inherit ( Boolean):見つからない値が継承元のコンポーネントから継承されるかどうかを定義します。
- dialogLayout（String）：ダイアログの開き方を定義します。
cq:editConfig 子ノード:
- cq:dropTargets (ノードタイプ nt:unstructured):コンテンツファインダーのアセットからのドロップを受け入れることができるドロップターゲットのリストを定義します。
  - 複数のドロップターゲットはクラシック UI でのみ使用できます。
  - タッチ操作対応 UI では、単一のドロップターゲットが許可されます。
- cq:actionConfigs (ノードタイプ nt:unstructured):cq:actionsリストに追加される新しいアクションのリストを定義します。
- cq:formParameters (ノードタイプ nt:unstructured):ダイアログフォームに追加する追加のパラメーターを定義します。
- cq:inplaceEditing (ノードタイプ cq:InplaceEditingConfig):コンポーネントのインプレイス編集設定を定義します。
- cq:listeners (ノードタイプ cq:EditListenersConfig):コンポーネントでアクションが発生する前または後の動作を定義します。

メモ

このページでは、ノード（プロパティおよび子ノード）は、次の例に示すように XML として表現されます。

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:dialogMode="floating"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
    <cq:listeners
        jcr:primaryType="cq:EditListenersConfig"
        afteredit="REFRESH_PAGE"/>
</jcr:root>

リポジトリには、既存の設定が多数あります。ユーザーは、特定のプロパティや子ノードを簡単に検索できます。

cq:editConfig ノードのプロパティ、例えば cq:actions を探すには、CRXDE Lite のクエリツールで、次の XPath クエリ文字列を指定して、検索を実行します。

//element(cq:editConfig, cq:EditConfig)[@cq:actions]
cq:editConfigの子ノードを探す場合、例えばcq:DropTargetConfig型のcq:dropTargetsを探すことができます。クエリツール(CRXDE Lite内)を使用して、次のXPathクエリ文字列で検索できます。

//element(cq:dropTargets, cq:DropTargetConfig)

コンポーネントプレースホルダ

コンポーネントにコンテンツがない場合でも、コンポーネントは常に、作成者に表示される一部のHTMLをレンダリングする必要があります。そうしないと、視覚的にエディターのインターフェイスから見えなくなり、技術的には表示されますが、ページやエディターには表示されなくなります。この場合、作成者は空のコンポーネントを選択して操作することができません。

このため、ページがページエディターでレンダリングされる（WCMモードがeditまたはpreviewの場合）際に、コンポーネントは表示された出力をレンダリングしない限り、プレースホルダーをレンダリングする必要があります。
プレースホルダーの一般的なHTMLマークアップは次のとおりです。

<div class="cq-placeholder" data-emptytext="Component Name"></div>

上記のプレースホルダーHTMLをレンダリングする一般的なHTLスクリプトは次のとおりです。

<div class="cq-placeholder" data-emptytext="${component.properties.jcr:title}"
     data-sly-test="${(wcmmode.edit || wcmmode.preview) && isEmpty}"></div>

前の例では、isEmptyは変数で、コンポーネントにコンテンツがなく、作成者には見えない場合にのみtrueになります。

繰り返しを避けるために、Adobeでは、コンポーネントの実装者に対して、コアコンポーネントが提供するプレースホルダーのようにHTLテンプレートをこれらのプレースホルダーに使用するように推奨します。

その後、前のリンクでのテンプレートの使用は、次のHTL行で行います。

<sly data-sly-use.template="core/wcm/components/commons/v1/templates.html"
     data-sly-call="${template.placeholder @ isEmpty=!model.text}"></sly>

前の例では、model.textは変数で、コンテンツが含まれ、表示されている場合にのみtrueになります。

このテンプレートの使用例は、コアコンポーネント（タイトルコンポーネントなど）で確認できます。

cq:EditConfig プロパティを使用した設定

cq:actions

cq:actionsプロパティ(String array)は、コンポーネントに対して実行できる1つまたは複数のアクションを定義します。設定に使用できる値を以下に示します。

プロパティの値	説明
`text:<some text>`	静的テキスト値 <some text> が表示されます。クラシック UI でのみ表示可能です。タッチ操作対応 UI は、アクションがコンテキストメニューに表示されないので、適用されません。
-	スペーサーを追加します. クラシック UI でのみ表示可能です。タッチ操作対応 UI は、アクションがコンテキストメニューに表示されないので、適用されません。
`edit`	コンポーネントを編集するボタンを追加します.
`editannotate`	コンポーネントを編集するボタンを追加し、注釈を許可します。
`delete`	コンポーネントを削除するボタンを追加します
`insert`	現在のコンポーネントの前に新しいコンポーネントを挿入するボタンを追加します
`copymove`	コンポーネントをコピーして切り取るボタンを追加します.

次の設定では、編集ボタン、スペーサー、削除ボタンおよび挿入ボタンがコンポーネントの編集バーに追加されます。

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit,-,delete,insert]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig"/>

次の設定では、「Inherited Configurations from Base Framework」というテキストがコンポーネントの編集バーに追加されます。

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[text:Inherited Configurations from Base Framework]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig"/>

cq:layout（クラシックUIのみ）

cq:layoutプロパティ(String)は、クラシックUIでのコンポーネントの編集方法を定義します。使用可能な値を次に示します。

プロパティの値	説明
`rollover`	デフォルト値. コンポーネントを編集するには、「マウスポインターを重ねて」クリックするか、コンテキストメニューを使用します。高度な使用の場合、対応するクライアント側のオブジェクトは次のとおりです。 `CQ.wcm.EditRollover`.
`editbar`	コンポーネントを編集するには、ツールバーを使用します。高度な使用の場合、対応するクライアント側のオブジェクトは次のとおりです。 `CQ.wcm.EditBar`.
`auto`	クライアント側のコードによって方法が選択されます。

メモ

rollover と editbar の概念は、タッチ操作対応 UI では適用されません。

次の設定では、編集ボタンがコンポーネントの編集バーに追加されます。

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
</jcr:root>

cq:dialogMode（クラシックUIのみ）

コンポーネントを編集ダイアログにリンクできます。cq:dialogModeプロパティ(String)は、クラシックUIでコンポーネントダイアログを開く方法を定義します。使用可能な値を次に示します。

プロパティの値	説明
`floating`	ダイアログが浮動になります。
`inline`	（デフォルト値）。ダイアログがコンポーネント上に固定されます。
`auto`	コンポーネントの幅がクライアント側の `CQ.themes.wcm.EditBase.INLINE_MINIMUM_WIDTH` 値よりも小さい場合、ダイアログは floating になります。それ以外の場合は、inline になります。

メモ

タッチ操作対応 UI のダイアログは、デスクトップモードでは常に浮動し、モバイルでは自動的に全画面表示として開きます。

次の設定では、編集ボタンを含む編集バーと浮動ダイアログが定義されます。

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0"
    cq:actions="[edit]"
    cq:dialogMode="floating"
    cq:layout="editbar"
    jcr:primaryType="cq:EditConfig">
</jcr:root>

cq:emptyText

cq:emptyTextプロパティ(String)は、視覚的なコンテンツがない場合に表示されるテキストを定義します。デフォルトは次のとおりです。Drag components or assets here.

cq:inherit

cq:inheritプロパティ(boolean)は、見つからない値が継承元のコンポーネントから継承されるかどうかを定義します。デフォルトはfalseです。

dialogLayout

dialogLayout プロパティは、デフォルトのダイアログの開き方を定義します。

fullscreenという値を指定すると、ダイアログがフルスクリーンで開きます。
値が空かプロパティがない場合、デフォルトでは通常どおりにダイアログが開きます。
ユーザーは、ダイアログ内で全画面モードを常に切り替えることができます。
クラシック UI には適用されません。

cq:EditConfig の子ノードを使用した設定

cq:dropTargets

cq:dropTargetsノード（ノードタイプnt:unstructured）は、コンテンツファインダーからドラッグされたアセットからのドロップを受け入れるドロップターゲットのリストを定義します。これは、タイプ cq:DropTargetConfig のノードのコレクションとして機能します。

メモ

複数のドロップターゲットはクラシック UI でのみ使用できます。

タッチ操作対応 UI では、最初のターゲットのみが使用されます。

タイプcq:DropTargetConfigの各子ノードは、コンポーネント内でドロップターゲットを定義します。ノード名は重要です。ノード名は、JSP で次のように使用して、有効なドロップターゲットである DOM 要素に割り当てられる CSS クラス名を生成する必要があるからです。

<drop target css class> = <drag and drop prefix> + 
 <node name of the drop target in the edit configuration>

<*drag and drop prefix*>はJavaプロパティで定義されます。

com.day.cq.wcm.api.components.DropTarget.CSS_CLASS_PREFIX.

例えば、ダウンロードコンポーネントのJSPでは、クラス名は次のように定義されます
( /libs/foundation/components/download/download.jsp)。ここでfileは、ダウンロードコンポーネントの編集設定でのドロップターゲットのノード名です。

String ddClassName = DropTarget.CSS_CLASS_PREFIX + "file";

タイプ cq:DropTargetConfig のノードには、次のプロパティが必要です。

プロパティ名	プロパティの値
`accept`	ドロップを許可するかどうかを検証するためにアセット MIME タイプに適用される regex。
`groups`	ドロップターゲットグループの配列。各グループは、コンテンツファインダーの拡張子に定義されていて、アセットに付加されているグループタイプに一致する必要があります。
`propertyName`	有効なドロップの後に更新されるプロパティの名前。

次の設定は、ダウンロードコンポーネントから取得されます。この設定では、media グループの任意のアセット（MIME タイプが任意の文字列でよい）をコンテンツファインダーからコンポーネントにドロップすることが可能です。ドロップをおこなうと、コンポーネントのプロパティ fileReference が更新されます。

    <cq:dropTargets jcr:primaryType="nt:unstructured">
        <file
            jcr:primaryType="cq:DropTargetConfig"
            accept="[.*]"
            groups="[media]"
            propertyName="./fileReference"/>
    </cq:dropTargets>

cq:actionConfigs（クラシックUIのみ）

cq:actionConfigsノード（ノードタイプnt:unstructured）は、cq:actionsプロパティで定義されたリストに追加される新しいアクションのリストを定義します。 cq:actionConfigs のそれぞれの子ノードでは、ウィジェットを定義することにより新しいアクションを定義します。

次の設定例では、（クラシック UI 用の区切り文字を持つ）新しいボタンを定義しています。

xtype tbseparator で定義される区切り文字。
- クラシック UI でのみ使用されます。
- タッチ操作対応 UI では xtype が無視されるので、この定義は無視されます（また、タッチ操作対応 UI ではアクションツールバーの構造が異なるので、区切り文字は不要です）。
コメントの管理という名前のボタン。このボタンは、ハンドラー関数CQ_collab_forum_openCollabAdmin()を実行します。

<jcr:root xmlns:cq="https://www.day.com/jcr/cq/1.0" xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:nt="https://www.jcp.org/jcr/nt/1.0"
    cq:actions="[EDIT,COPYMOVE,DELETE,INSERT]"
    jcr:primaryType="cq:EditConfig">
    <cq:actionConfigs jcr:primaryType="nt:unstructured">
        <separator0
            jcr:primaryType="nt:unstructured"
            xtype="tbseparator"/>
        <manage
            jcr:primaryType="nt:unstructured"
            handler="function(){CQ_collab_forum_openCollabAdmin();}"
            text="Manage comments"/>
    </cq:actionConfigs>
</jcr:root>

メモ

タッチ操作対応 UI の例については、新しいアクションのコンポーネントツールバーへの追加を参照してください。

cq:formParameters

cq:formParametersノード（ノードタイプnt:unstructured）は、ダイアログフォームに追加される追加のパラメーターを定義します。各プロパティは、form パラメーターにマップされます。

次の設定では、値 name が設定された photos/primary という名前のパラメーターがダイアログフォームに追加されます。

    <cq:formParameters
        jcr:primaryType="nt:unstructured"
        name="photos/primary"/>

cq:inplaceEditing

cq:inplaceEditingノード（ノードタイプcq:InplaceEditingConfig）は、コンポーネントのインプレイス編集設定を定義します。このノードは、次のプロパティを持つことができます。

プロパティ名	プロパティの値
`active`	(`boolean`) Trueを指定すると、コンポーネントのインプレイス編集が有効になります。
`configPath`	（`String`）エディター設定のパス。設定は、設定ノードで指定できます。
`editorType`	(`String`)エディタタイプ。指定できるタイプを次に示します。 plaintext：コンテンツが HTML 以外の場合に使用します。 title：編集を開始する前にグラフィカルなタイトルをプレーンテキストに変換する拡張プレーンテキストエディター。Geometrixx タイトルコンポーネントで使用されます。 text：コンテンツが HTML の場合に使用します（リッチテキストエディターを使用）。

次の設定では、コンポーネントのインプレース編集が可能になり、テキストエディターとして plaintext が定義されます。

    <cq:inplaceEditing
        jcr:primaryType="cq:InplaceEditingConfig"
        active="{Boolean}true"
        editorType="plaintext"/>

cq:listeners

cq:listenersノード（ノードタイプcq:EditListenersConfig）は、コンポーネントに対するアクションの前後に何が起こるかを定義します。次の表では、使用する可能性のあるプロパティ値の定義を示します。

プロパティ名	プロパティの値	デフォルト値（クラシック UI のみ）
`beforedelete`	コンポーネントを削除する前にハンドラーが呼び出されます。
`beforeedit`	コンポーネントを編集する前にハンドラーが呼び出されます。
`beforecopy`	コンポーネントをコピーする前にハンドラーが呼び出されます。
`beforemove`	コンポーネントを移動する前にハンドラーが呼び出されます。
`beforeinsert`	コンポーネントを挿入する前にハンドラーが呼び出されます。タッチ対応UIでのみ動作します。
`beforechildinsert`	コンポーネントを別のコンポーネント（コンテナのみ）の内部に挿入する前にハンドラーが呼び出されます。
`afterdelete`	コンポーネントを削除した後にハンドラーが呼び出されます。	`REFRESH_SELF`
`afteredit`	ハンドラーは、コンポーネントの編集後にトリガーされます。	`REFRESH_SELF`
`aftercopy`	ハンドラーは、コンポーネントのコピー後にトリガーされます。	`REFRESH_SELF`
`afterinsert`	ハンドラーは、コンポーネントの挿入後にトリガーされます。	`REFRESH_INSERTED`
`aftermove`	コンポーネントを移動した後にハンドラーが呼び出されます。	`REFRESH_SELFMOVED`
`afterchildinsert`	ハンドラーは、コンポーネントが別のコンポーネント内に挿入された後にトリガーされます(コンテナのみ)。

メモ

REFRESH_INSERTEDおよびREFRESH_SELFMOVEDハンドラーは、クラシックUIでのみ使用できます。

メモ

リスナーのデフォルト値は、クラシック UI にのみ設定されています。

メモ

コンポーネントがネストされている場合は、cq:listeners ノードでプロパティとして定義されるアクションに一定の制限があります。

コンポーネントがネストされている場合、次のプロパティの値を にする必要があります。REFRESH_PAGE
aftermove
aftercopy

イベントハンドラーを実装するときは、カスタム実装を組み込むことができます。次に例を示します（project.customerAction は静的メソッドです）。

afteredit = "project.customerAction"

次の例はREFRESH_INSERTED設定と同じです。

afterinsert="function(path, definition) { this.refreshCreated(path, definition); }"

メモ

クラシックUIでは、ハンドラーで使用できるイベントーを確認するには、ウィジェットドキュメント CQ.wcm.EditBarおよび CQ.wcm.EditRolloverのbefore<action>パラメーターとafter<action>の節を参照してください。

次の設定では、コンポーネントを削除、編集、挿入または移動した後にページが更新されます。

    <cq:listeners
        jcr:primaryType="cq:EditListenersConfig"
        afterdelete="REFRESH_PAGE"
        afteredit="REFRESH_PAGE"
        afterinsert="REFRESH_PAGE"
        afterMove="REFRESH_PAGE"/>

adobe.com 上のリソース

Style System Customer Communications Personalized Communications Responsive Forms Managed Cloud Version History

このページ

次を表示：

プライバシー（更新済み）

利用規約