現在表示中:

AEM コンポーネントを使用して、Web ページ上で使用できるコンテンツを保持、書式設定およびレンダリングします。

  • ページをオーサリングするとき、作成者はコンポーネントを使用してコンテンツを編集および設定できます。
    • コマースサイトを構築するときは、コンポーネントを使用して、例えばカタログの情報を収集してレンダリングできます。
      詳しくは、e コマースの開発を参照してください。
    • コミュニティサイトを構築するときは、コンポーネントを使用して、訪問者に情報を提供したり、訪問者から情報を収集したりできます。
      詳しくは、コミュニティの開発を参照してください。
  • パブリッシュインスタンス上では、コンポーネントがコンテンツをレンダリングし、適切なタイミングで Web サイト訪問者に表示します。

注意:

このページの内容は、AEM コンポーネント - 基本を踏まえたものです。

警告:

/libs/cq/gui/components/authoring/dialog の下にあるコンポーネントは、エディター(オーサリングのコンポーネントダイアログ)で使用することのみが意図されています。他の場所で使用すると(インスタンスのウィザードダイアログ内など)、予期したとおりに動作しないことがあります。

コードサンプル

このページでは、タッチ操作向け UI 用の新しいコンポーネントの開発に必要なリファレンスドキュメント(またはリファレンスドキュメントへのリンク)を提供します。実践的な例は、タッチ操作向け UI 用の AEM コンポーネントの開発 - コードサンプルを参照してください。

構造

コンポーネントの基本構造については、AEM コンポーネント - 基本で説明しています。この節では、タッチ操作向け UI とクラシック UI の両方を扱います。新しいコンポーネントでクラシック設定を使用する必要がない場合でも、既存コンポーネントから継承する際にクラシック設定について知っていると役立ちます。

既存のコンポーネントおよびダイアログの拡張

実装するコンポーネントによっては、構造全体を一から定義して開発するのではなく、既存インスタンスを拡張したり、カスタマイズしたりするだけで済むことがあります。

既存のコンポーネントまたはダイアログを拡張またはカスタマイズする際に、構造全体またはダイアログに必要な構造をコピーまたは複製してから変更することができます。

既存コンポーネントの拡張

既存コンポーネントは、リソースタイプ階層と関連する継承メカニズムを使用して拡張できます。

注意:

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

注意:

コンテンツフラグメントコンポーネントもカスタマイズおよび拡張できますが、構造全体やアセットとの関係を考慮する必要があります。

既存のコンポーネントダイアログのカスタマイズ

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

つまり、ダイアログ全体を(sling:resourceSuperType を使用して)再定義するのとは対照的に、再定義する必要があるのは相違点だけです。これは、推奨されるコンポーネントダイアログ拡張方法です。

詳しくは、Sling Resource Merger を参照してください。

マークアップの定義

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

HTML テンプレート言語の使用

HTML テンプレート言語(HTL)は、AEM 6.0 で JSP(JavaServer Pages)に代わって導入されたスクリプティング言語であり、HTML の扱いに適した、推奨されるサーバー側テンプレートシステムです。堅牢なエンタープライズ Web サイトを構築しなければならない Web 開発者にとって、HTL は安全性と開発効率の向上に役立ちます。

注意:

HTL と JSP のどちらを使用してもタッチ操作向け UI 用のコンポーネントを開発できますが、AEM の推奨スクリプティング言語は HTL なので、ここでは HTL を使用した開発について説明します。

コンテンツロジックの開発

このオプションのロジックでは、レンダリングするコンテンツの選択や計算をおこないます。このロジックは、適切な Use-API パターンを持つ HTL 式から呼び出されます。

このようにロジックを外観から分離するメカニズムは、特定のビューで何が呼び出されるかを明確化するために役立ちます。同じリソースの異なるビューに対し、異なるロジックを使用することもできます。

Java の使用

HTL Java Use-API を使用すると、HTL ファイルからカスタム Java クラスのヘルパーメソッドへのアクセスが可能になります。そのため、Java コードを使用して、コンポーネントのコンテンツを選択および設定するためのロジックを実装できます。

JavaScript の使用

HTL JavaScript Use-API を使用すると、HTL ファイルから JavaScript で書かれたヘルパーコードへのアクセスが可能になります。そのため、JavaScript コードを使用して、コンポーネントのコンテンツを選択および設定するためのロジックを実装できます。

クライアント側 HTML ライブラリの使用

最近の Web サイトは、複雑な JavaScript や CSS コードを利用したクライアント側の処理に大きく依存しています。このコードの提供を編成および最適化することが厄介な問題となることがあります。

この問題への対処に役立つように、AEM では、クライアント側ライブラリフォルダーが提供されています。これにより、クライアント側コードをリポジトリに格納し、カテゴリ別に整理して、それぞれのカテゴリのコードをクライアントに提供するタイミングと方法を定義することができます。その後、クライアント側ライブラリシステムにより、最終的な Web ページで、正しいコードを読み込むための正しいリンクが作成されます。

詳しくは、クライアント側 HTML ライブラリの使用を参照してください。

編集動作の設定

コンポーネントの編集動作を設定できます。編集動作には、コンポーネントに使用できるアクション、インプレースエディターの特性、コンポーネントに対するイベントに関連するリスナーなどの属性が含まれます。固有の相違点は多少ありますが、設定はタッチ操作向け UI とクラシック UI の両方に共通です。

コンポーネントの編集動作を設定するには、タイプ cq:EditConfigcq:editConfig ノードをコンポーネントノード(タイプ cq:Component)の下に追加し、特定のプロパティと子ノードを追加します。

プレビュー動作の設定

タッチ操作向け UI でプレビューモードに切り替えると、ページを更新しなくても WCM モード cookie が設定されます。

レンダリングが WCM モードの影響を受けるコンポーネントの場合は、明確にそのコンポーネントを更新し、この cookie の値を使用するように定義する必要があります。

注意:

EDITPREVIEW は、タッチ操作向け UI でのみ WCM モード cookie に使用されます。

ダイアログの作成と設定

作成者はダイアログを使用してコンポーネントとやり取りできます。ダイアログを使用することで、作成者や管理者はコンテンツを編集したり、コンポーネントを設定したり、(デザインダイアログを使用して)デザインパラメーターを定義したりできます。

Coral UI と Granite UI

タッチ操作向け UI では、ルックアンドフィールに Coral UIGranite UI を利用しています。

Granite UI で提供される幅広い基本コンポーネント(ウィジェット)は、オーサー環境でダイアログを作成するために使用されます。必要な場合には、選択したウィジェットを拡張し、独自のウィジェットを作成することができます。

詳しくは、以下を参照してください。

注意:

Granite UI コンポーネントの性質(および ExtJS ウィジェットとの違い)により、タッチ操作向け UI とクラシック UI では、コンポーネントとのやり取りにいくつかの相違点があります。

新しいダイアログの作成

タッチ操作向け UI 用ダイアログは、以下のように実装されます。

  • cq:dialog という名前です。
  • sling:resourceType プロパティが設定された nt:unstructured ノードとして定義されます。
  • cq:Component ノードの下のコンポーネント定義の横にあります。
  • コンテンツ構造と sling:resourceType プロパティに基づいて、サーバー側で(Sling コンポーネントとして)レンダリングされます。
  • Granite UI フレームワークを使用します。
  • ダイアログ内のフィールドを記述したノード構造を含みます。
    • これらのノードは、必須の sling:resourceType プロパティを持つ nt:unstructured ノードです。

ノード構造の例は次のようになります。

newComponent (cq:Component)
  cq:dialog (nt:unstructured)
    content 
      layout 
      items 
        column 
          items 
            file  
            description  

ダイアログ自体が一種のコンポーネント(コンポーネントスクリプトによって動作と一緒にレンダリングされるマークアップや、クライアントライブラリが提供するスタイルなど)なので、ダイアログのカスタマイズはコンポーネントのカスタマイズに似ています。

例えば、次を参照してください。

  • /libs/foundation/components/text/cq:dialog
  • /libs/foundation/components/download/cq:dialog

注意:

コンポーネントにタッチ操作向け UI 用のダイアログが定義されていない場合は、クラシック UI ダイアログが互換性レイヤー内でフォールバックとして使用されます。そのようなダイアログをカスタマイズするには、クラシック UI ダイアログをカスタマイズする必要があります。詳しくは、クラシック UI 用の AEM コンポーネントを参照してください。

ダイアログフィールドのカスタマイズ

注意:

次のページを参照してください。

新しいフィールドの作成

タッチ操作向け UI 用のウィジェットは、Granite UI コンポーネントとして実装されています。

タッチ操作向け UI 用のコンポーネントダイアログで使用する新しいウィジェットを作成するには、新しい Granite UI フィールドコンポーネントを作成する必要があります。

注意:

Granite UI について詳しくは、Granite UI ドキュメントを参照してください。

ダイアログをフォーム要素のシンプルなコンテナと見なす場合は、ダイアログコンテンツの主要コンテンツをフォームフィールドと見なすこともできます。新しいフォームフィールドを作成するには、リソースタイプを作成する必要があります。これは、新しいコンポーネントの作成と同等です。この作業を容易にするために、Granite UI は、sling:resourceSuperType を使用して以下を継承する汎用フィールドコンポーネントを提供しています。

/libs/granite/ui/components/foundation/form/field

より正確に言えば、Granite UI には、ダイアログ(より一般的に言えばフォーム)での使用に適した、幅広いフィールドコンポーネントが用意されています。

注意:

この点はクラシック UI とは異なります。クラシック UI では、ウィジェットは cq:Widgets ノードによって表され、各ノードには対応する ExtJS ウィジェットとの関係を確立するための特定の xtype があります。実装の観点から、これらのウィジェットは ExtJS フレームワークによってクライアント側でレンダリングされていました。

注意:

そのようなコンポーネントは、今でも HTL ではなく JSP で記述されます。フォームフィールドは特殊だからです。フォームフィールドは、リクエストを通じてスクリプト間で値を受け渡す処理に大きく依存しており、このアクションは現在の HTL では不可能です。したがって、フォームフィールドは(例外的に)引き続き JSP で記述する必要があります。

リソースタイプを作成した上で、sling:resourceType プロパティで作成したリソースタイプを参照して、新しいノードをダイアログに追加することによって、フィールドをインスタンス化できます。

スタイル設定および動作用のクライアントライブラリの作成

コンポーネントのスタイル設定と動作を定義する場合は、カスタム CSS/LESS および JS を定義する専用のクライアントライブラリを作成できます。

クライアントライブラリをコンポーネントダイアログ専用に読み込む(すなわち、別のコンポーネント用には読み込まれないようにする)には、ダイアログの extraClientLibs プロパティを、作成したクライアントライブラリのカテゴリ名に設定する必要があります。 この方法は、クライアントライブラリが非常に大きい場合や、フィールドがそのダイアログに固有で、他のダイアログで必要になることがない場合にお勧めです。

クライアントライブラリをすべてのダイアログ用に読み込むには、クライアントライブラリのカテゴリプロパティを cq.authoring.dialog に設定します。これは、すべてのダイアログのレンダリング時にデフォルトで含まれるクライアントライブラリのカテゴリ名です。クライアントライブラリが小さい場合や、フィールドが汎用的で、他のダイアログで再利用できる場合には、この方法を使用できます。

例えば、次を参照してください。

フィールドの拡張(フィールドからの継承)

要件に応じて、次のどちらかを実行できます。

  • コンポーネントの継承(sling:resourceSuperType)によって、指定された Granite UI フィールドを拡張する
  • ウィジェットライブラリ API(JS/CSS 継承)に従って、指定されたウィジェットを基となるウィジェットライブラリ(Granite UI の場合は Coral UI)から拡張する

ダイアログフィールドへのアクセス

レンダリング条件(rendercondition)を使用して、ダイアログ内の特定のタブやフィールドへのアクセス権を持つユーザーを制御することもできます。以下に例を示します。

+ mybutton
  - sling:resourceType = granite/ui/components/foundation/button
  + rendercondition
    - sling:resourceType = myapp/components/renderconditions/group
    - groups = ["administrators"]

フィールドイベントの処理

ダイアログフィールドのイベントの処理は、カスタムクライアントライブラリのリスナー(タッチ操作向け UI)で行なわれるようになりました。これは以前の方法からの変更点です。以前は、コンテンツ構造のリスナー(ExtJS を備えたクラシック UI)を使用していました。

カスタムクライアントライブラリのリスナー

フィールドにロジックを挿入するには、以下を実行する必要があります。

  1. 対象となるフィールドを、指定された CSS クラス(フック)でマークします。
  2. クライアントライブラリ内で、その CSS クラス名に対してフックされる JS リスナーを定義します(これによって、カスタムロジックの範囲がそのフィールドのみに限定され、同じタイプの他のフィールドに影響を与えなくなります)。

これを実現するには、やり取りする、基になるウィジェットライブラリについて理解する必要があります。反応するイベントの識別については、Coral UI ドキュメントを参照してください(ExtJS を使用して実行する必要があったプロセスと非常によく似ています。指定されたウィジェットのドキュメントページを探し、そのイベント API の詳細を確認してください)。

例えば、次を参照してください。

コンテンツ構造のリスナー(クラシック UI)

ExtJS を使用するクラシック UI では、コンテンツ構造内に指定のウィジェットのリスナーを用意することが普通でした。タッチ UI では、同じことを別の方法で実現します。JS のリスナーコード(またはあらゆるコード)はコンテンツ内で定義されないからです。

コンテンツ構造は意味構造を記述するものであり、基となるウィジェットの性質を示すものであってはなりません。コンテンツ構造に JS コードを含めないことで、コンテンツ構造を変更せずに実装の詳細を変更することが可能になります。言い換えると、コンテンツ構造に触れることなく、ウィジェットライブラリを変更できます。

フィールドの検証

必須フィールド

指定されたフィールドを「必須」としてマークするには、フィールドのコンテンツノードに次のプロパティを設定します。

  • 名前:required
  • タイプ:Boolean

例えば、次を参照してください。

/libs/foundation/components/page/cq:dialog/content/items/tabs/items/basic/items/column/items/title/items/title

フィールドの検証(Granite UI)

Granite UI でのフィールド検証および Granite UI コンポーネント(ウィジェットと同等)のフィールド検証は、基本バリデーター API を使用して実行します。詳しくは、基本バリデーターに関する Granite のドキュメントを参照してください。

例えば、次を参照してください。

  • cqgems/customizingfield/components/clientlibs/customizingfield/js/validations.js
  • /etc/scaffolding/geometrixx-outdoors/clientlibs-touch/validators.js
  • /libs/cq/gui/components/authoring/dialog/clientlibs/dialog/js/validations.js

注意:

クラシック UI 向けの同等の例は、以下で参照できます。

/etc/scaffolding/geometrixx-outdoors/clientlibs-classic/validators.js

デザインダイアログの作成と設定

コンポーネントにデザインモードで編集できるデザイン詳細がある場合は、デザインダイアログを用意します。

デザインダイアログの定義は、コンテンツの編集に使用されるダイアログの定義によく似ています。違いはノードとして定義される点です。

  • ノード名:cq:design_dialog
  • タイプ:nt:unstructured

インプレースエディターの作成と設定

インプレースエディターは、ユーザーがコンテンツを編集するときに、ダイアログを開かずに、段落フロー内で直接編集できるようにする機能です。例えば、標準のテキストコンポーネントとタイトルコンポーネントには、どちらもインプレースエディターがあります。

インプレースエディターは、すべてのコンポーネントタイプで必要または重要なものではありません。

コンポーネントツールバーのカスタマイズ

コンポーネントツールバーは、ユーザーがコンポーネントの幅広いアクション(編集、設定、コピー、削除など)にアクセスできるようにする機能です。

参照レール用のコンポーネント(借りた/貸したコンテンツ)の設定

新しいコンポーネントが他のページのコンテンツを参照する場合は、参照レールの「借りたコンテンツ」セクションおよび「貸したコンテンツ」セクションに影響を与えるかどうかを考慮できます。

初期状態の AEM は参照コンポーネントのみを確認します。コンポーネントを追加するには、OSGi バンドル WCM オーサリングコンテンツ参照設定を設定する必要があります。

定義に新しいエントリを作成し、確認するプロパティと共にコンポーネントを指定します。例を以下に示します。

/apps/<your-Project>/components/reference@parentPath

注意:

AEM を操作しているときは、このようなサービスの設定を管理する方法がいくつかあります。詳細および推奨事項については、OSGi の設定を参照してください。

コンポーネントの有効化と段落システムへの追加

コンポーネントを開発したら、必要なページで使用できるよう、適切な段落システムでの使用を有効にする必要があります。

次のどちらかの方法で有効化できます。

アセットをドラッグするとコンポーネントインスタンスが作成されるように段落システムを設定

AEM では、ページの段落システムを設定するときに、常に空のコンテンツをページにドラッグするのではなく、ユーザーが(適切な)アセットをページのインスタンスにドラッグすると新しいコンポーネントのインスタンスが自動的に作成されるような設定にすることができます。

この動作と、必要なアセットとコンポーネントの関連付けは、次の方法で設定できます。

  1. 次のようなページデザインの段落定義の下に、

    • /etc/designs/<myApp>/page/par

    新しいノードを作成します。

    • 名前:cq:authoring
    • タイプ:nt:unstructured
  2. この下に、アセットとコンポーネントのマッピングをすべて保持する新しいノードを作成します。

    • 名前:assetToComponentMapping
    • タイプ:nt:unstructured
  3. アセットとコンポーネントのマッピングごとに、ノードを作成します。

    • 名前:テキスト。アセットと関連するコンポーネントタイプを示す名前(例:image)にすることを推奨します。
    • タイプ:nt:unstructured

    それぞれが以下のプロパティを持ちます。

    • assetGroup
      • タイプ:String
      • 値:関連アセットが所属するグループ(例:media
    • assetMimetype
      • タイプ:String
      • 値:関連アセットの MIME タイプ(例:image/*
    • droptarget
      • タイプ:String
      • 値:ドロップターゲット(例:image
    • resourceType
      • タイプ:String
      • 値:関連コンポーネントリソース(例:foundation/components/image
    • type
      • タイプ:String
      • 値:タイプ(例:Images

例えば、次を参照してください。

  • /etc/designs/geometrixx/jcr:content/page/par/cq:authoring
  • /etc/designs/geometrixx-outdoors/jcr:content/page/par/cq:authoring
  • /etc/designs/geometrixx-media/jcr:content/article/article-content-par/cq:authoring

GitHub のコード

このページのコードは GitHub にあります

  • GitHub の aem-project-archetype プロジェクトを開きます
  • プロジェクトを ZIP ファイルとしてダウンロードします

AEM Brackets 拡張の使用

AEM Brackets 拡張は、AEM コンポーネントおよびクライアントライブラリを編集するためのスムーズなワークフローを提供します。この拡張は、Brackets コードエディターをベースとしています。

この拡張には、次の機能があります。

  • 同期を容易にして(Maven や File Vault が不要)、開発者の効率を向上させるだけでなく、AEM に関する知識が限られたフロントエンド開発者もプロジェクトに参加できるようにします。
  • コンポーネント開発の単純化やセキュリティ向上のために設計されたテンプレート言語 HTL を一部サポートしています。

注意:

Brackets は、タッチ操作向け UI 用のコンポーネントを作成するための推奨メカニズムです。Brackets は、クラシック UI 向けに設計された CRXDE Lite のコンポーネント作成機能の代わりになります。

クラシックコンポーネントからの移行

クラシック UI で使用するようにデザインされたコンポーネントを、タッチ操作向け UI 専用または両方の UI で使用できるコンポーネントに移行する場合は、以下の問題を考慮する必要があります。

cq:listener コードの移行

クラシック UI 向けにデザインされたプロジェクトを移行する場合は、cq:listener コード(およびコンポーネントに関連するクライアント側ライブラリ)でクラシック UI 固有の関数(CQ.wcm.*など)を使用できます。移行するには、タッチ操作向け UI 用の同等のオブジェクトまたは関数を使用して、このようなコードを更新する必要があります。

プロジェクトをタッチ操作向け UI に完全に移行する場合は、タッチ操作向け UI に関連するオブジェクトや関数を使用するように、このようなコードを置き換える必要があります。

ただし、移行期間中にプロジェクトがクラシック UI とタッチ操作向け UI の両方に対応する必要がある場合(通常のシナリオ)は、適切なオブジェクトを参照する別々のコードを区別するためのスイッチを実装する必要があります。

このスイッチメカニズムは、次のように実装できます。

if (Granite.author) {
    // touch UI
} else {
    // classic UI
}

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー