コンポーネントのオーバーレイ

コンポーネントは、検索パスロジックに基づいたオーバーレイを使用して再定義することもできます。ただし、その場合 Sling Resource Merger が呼び出されないので、/apps でオーバーレイ全体を定義する必要があります。

コンポーネントダイアログの拡張

Sling Resource Merger を使用し、sling:resourceSuperType プロパティを定義して、コンポーネントダイアログをオーバーライドすることもできます。

つまり、ダイアログ全体を再定義するのとは対照的に、再定義する必要があるのは相違点だけです。

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

コンポーネントは HTML を使用してレンダリングされます。コンポーネントでは、必要なコンテンツを取得して、オーサー環境とパブリッシュ環境の両方で必要に応じてレンダリングするために必要な HTML を定義しなければなりません。

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

この方法をサポートするテンプレート言語が HTL です。HTL では、基盤となるビジネスロジックを定義するときにのみプログラミング言語を使用します。このメカニズムは、特定のビューに対して呼び出されるコードを強調表示し、必要に応じて、同じコンポーネントの異なるビューに対して特定のロジックを使用できるようにします。

この(オプション)ロジックは様々な方法で実装でき、特定のコマンドを使用して HTL から呼び出します。

  • Java の使用 - HTL Java Use-API を使用すると、HTL ファイルからカスタム Java クラスのヘルパーメソッドへのアクセスが可能になります。そのため、Java コードを使用して、コンポーネントのコンテンツを選択および設定するためのロジックを実装できます。
  • JavaScript の使用 - HTL JavaScript Use-API を使用すると、HTL ファイルから JavaScript で書かれたヘルパーコードへのアクセスが可能になります。この結果、JavaScript コードを使用して、コンポーネントのコンテンツを選択および設定するためのロジックを実装できます。
  • クライアントサイドライブラリの使用 - 最近の Web サイトは、複雑な JavaScript や CSS コードを利用したクライアントサイド処理に大きく依存しています。詳しくは、「AEM as a Cloud Service でのクライアントサイドライブラリの使用」ドキュメントを参照してください。

コンポーネント構造

AEM コンポーネントの構造は強力で柔軟性があります。以下は主な部分です。

リソースタイプ

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

  • コンテンツの構造は意図を宣言します。
  • これらは、リソースタイプによって実装されます。

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

コンポーネント定義

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

  • AEM コンポーネントは、Sling に基づいています。

  • AEM コンポーネントは、/libs/core/wcm/components の下に配置されています。

  • プロジェクトまたはサイトに固有のコンポーネントは、/apps/<myApp>/components の下に配置されています。

  • AEM の標準コンポーネントは、cq:Component として定義され、次の主要な構成要素を持ちます。

    • jcr プロパティ - jcr プロパティのリスト。これらは可変であり、コンポーネントノードの基本構造、そのプロパティ、およびサブノードは cq:Component 定義によって定義されますが、一部はオプションの場合があります。
    • リソース - コンポーネントが使用する静的要素を定義します。
    • スクリプト - コンポーネントの結果インスタンスの動作を実装するために使用されます。

重要なプロパティ

  • ルートノード

    • <mycomponent> (cq:Component) - コンポーネントの階層ノード
  • 重要なプロパティ

    • jcr:title - コンポーネントのタイトル。例えば、コンポーネントをコンポーネントブラウザーおよびコンポーネントコンソールにリストする際にラベルとして使用されます。
    • jcr:description - コンポーネントの説明。コンポーネントブラウザーおよびコンポーネントコンソールで、ポインタを合わせると表示されるヒントとして使用されます。
    • 詳しくは、コンポーネントアイコンの節を参照してください。
  • 重要な子ノード

    • cq:editConfig (cq:EditConfig) - コンポーネントの編集プロパティを定義し、コンポーネントをコンポーネントブラウザーに表示できるようにします。
      • コンポーネントにダイアログがある場合は、cq:editConfig が存在しなくても、コンポーネントは自動的にコンポーネントブラウザーまたはサイドキックに表示されます。
    • cq:childEditConfig (cq:EditConfig) - 独自の cq:editConfig を定義しない子コンポーネントの作成者 UI 要素を制御します。
    • cq:dialog (nt:unstructured) - このコンポーネントのダイアログ。ユーザーがコンポーネントを設定したり、コンテンツを編集したりできるインターフェイスを定義します。
    • cq:design_dialog (nt:unstructured) - このコンポーネントのデザイン編集。

コンポーネントアイコン

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

  1. cq:icon - コンポーネントブラウザーで表示する Coral UI ライブラリの標準的なアイコンを指定する String プロパティ。

    • Coral アイコンの HTML 属性の値を使用します。
  2. abbreviation - コンポーネントブラウザーでのコンポーネント名の省略形をカスタマイズする String プロパティ。

    • 省略形は最大 2 文字までにする必要があります。

    • 空の文字列が指定されると、jcr:title プロパティの最初の 2 文字を使用して省略形が作成されます。

      • 例えば、「Image」の場合は「Im」になります。
      • ローカライズされたタイトルが省略形の作成に使用されます。
    • 省略形は、コンポーネントに abbreviation_commentI18n プロパティがある場合にのみ翻訳されます。これは、翻訳ヒントとして使用されます。

  3. cq:icon.png または cq:icon.svg - コンポーネントブラウザーに表示される、このコンポーネントのアイコン。

    • 20 x 20 ピクセルは、標準的なコンポーネントのアイコンのサイズです。
      • 大きいアイコンはクライアントサイドで縮小されます。
    • お勧めの色は、RGB(112、112、112)、つまり #707070 です。
    • 標準的なコンポーネントアイコンの背景は、透明です。
    • .png および .svg ファイルのみがサポートされます。
    • Eclipse プラグインを使用してファイルシステムから読み込む場合、例えば _cq_icon.png_cq_icon.svg のように、ファイル名をエスケープする必要があります。
    • 両方が存在する場合は、.png.svg よりも優先されます

コンポーネントで上述のプロパティ(cq:iconabbreviationcq:icon.png または cq:icon.svg)が見つからない場合:

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

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

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