Show Menu
トピック×

AEM コンポーネントの開発

AEM コンポーネントを使用して、Web ページ上で使用できるコンテンツを保持、書式設定およびレンダリングします。
  • ページをオーサリング するとき、作成者はコンポーネントを使用してコンテンツを編集および設定できます。
    • コマース サイトを構築するときは、コンポーネントを使用して、例えばカタログの情報を収集してレンダリングできます。詳しくは、 e コマースの開発 を参照してください。
    • コミュニティ サイトを構築するときは、コンポーネントを使用して、訪問者に情報を提供したり、訪問者から情報を収集したりできます。詳しくは、 コミュニティの開発 を参照してください。
  • パブリッシュインスタンス上では、コンポーネントがコンテンツをレンダリングし、適切なタイミングで Web サイト訪問者に表示します。
This page is a continuation of the document AEM Components - The Basics .
Components below /libs/cq/gui/components/authoring/dialog are meant to be used only in the Editor (component dialogs in Authoring). 他の場所で使用すると(インスタンスのウィザードダイアログ内など)、予期したとおりに動作しないことがあります。

コードサンプル

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

構造

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

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

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

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

既存コンポーネントは、 リソースタイプ階層 と関連する継承メカニズムを使用して拡張できます。
コンポーネントは、検索パスロジックに基づいたオーバーレイを使用して再定義することもできます。However in such case, the Sling Resource Merger will not be triggered and /apps must define the entire overlay.
コンテンツフラグメントコンポーネント もカスタマイズおよび拡張できますが、構造全体やアセットとの関係を考慮する必要があります。

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

This means you only need to redefine the required differences, as opposed to redefining the entire dialog (using sling:resourceSuperType ). これは、推奨されるコンポーネントダイアログ拡張方法です。
詳しくは、 Sling Resource Merger を参照してください。

マークアップの定義

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

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

HTML テンプレート言語(HTL) は、AEM 6.0 で JSP(JavaServer Pages)に代わって導入されたスクリプティング言語であり、HTML の扱いに適した、推奨されるサーバー側テンプレートシステムです。堅牢なエンタープライズ Web サイトを構築する必要のある Web 開発者にとって、HTL は安全性と開発効率の向上に役立ちます。
HTL と JSP のどちらを使用してもコンポーネントを開発できますが、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 コードを利用したクライアント側の処理に大きく依存しています。このコードの提供を編成および最適化することが厄介な問題となることがあります。
To help deal with this issue, AEM provides Client-side Library Folders , which allow you to store your client-side code in the repository, organize it into categories and define when and how each category of code is to be served to the client. その後、クライアント側ライブラリシステムにより、最終的な Web ページで、正しいコードを読み込むための正しいリンクが作成されます。
詳しくは、 クライアント側 HTML ライブラリの使用 を参照してください。

編集動作の設定

コンポーネントの編集動作を設定できます。編集動作には、コンポーネントに使用できるアクション、インプレースエディターの特性、コンポーネントに対するイベントに関連するリスナーなどの属性が含まれます。固有の相違点は多少ありますが、設定はタッチ操作対応 UI とクラシック UI の両方に共通です。
The edit behavior of a component is configured by adding a cq:editConfig node of type cq:EditConfig below the component node (of type cq:Component ) and by adding specific properties and child nodes.

プレビュー動作の設定

プレビュー ​モードに切り替えると、ページが更新されなくても WCM モード Cookie が設定されます。
レンダリングが WCM モードの影響を受けるコンポーネントの場合は、明確にそのコンポーネントを更新し、この Cookie の値を使用するように定義する必要があります。
EDIT PREVIEW は、タッチ操作対応 UI でのみ WCM モード Cookie に使用されます。

ダイアログの作成と設定

作成者はダイアログを使用してコンポーネントとやり取りできます。Using a dialog allows authors and/or administrators to edit content, configure the component or define design parameters (using a Design Dialog )

Coral UI と Granite UI

AEM の現代的なルックアンドフィールは Coral UI Granite UI で定義されています。
Granite UI で提供される幅広い基本コンポーネント(ウィジェット) は、オーサー環境でダイアログを作成するために使用されます。必要な場合には、選択したウィジェットを拡張し、 独自のウィジェットを作成 することができます。
Coral および Granite リソースタイプを使用してコンポーネントを開発する方法について詳しくは、 Coral/Granite リソースタイプを使用した Experience Manager コンポーネントの作成 を参照してください。
詳しくは、以下を参照してください。
Granite UI コンポーネントの性質(および ExtJS ウィジェットとの違い)により、タッチ操作対応 UI と クラシック UI では、コンポーネントとのやり取りにいくつかの相違点があります。

新しいダイアログの作成

タッチ操作対応 UI 用ダイアログは、以下のように実装されます。
  • are named cq:dialog .
  • are defined as an nt:unstructured node with the sling:resourceType property set.
  • cq:Component ノードの下のコンポーネント定義の横にあります。
  • コンテンツ構造と sling:resourceType プロパティに基づいて、サーバー側で(Sling コンポーネントとして)レンダリングされます。
  • Granite UI フレームワークを使用します。
  • ダイアログ内のフィールドを記述したノード構造を含みます。
    • these nodes are nt:unstructured with the required sling:resourceType property.
ノード構造の例は次のようになります。
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/coral/foundation/form/field
より正確に言えば、Granite UI には、ダイアログ(より一般的に言えば フォーム )での使用に適した、幅広いフィールドコンポーネントが用意されています。
この点はクラシック UI とは異なります。クラシック UI では、ウィジェットは cq:Widgets ノードによって表され、各ノードには対応する ExtJS ウィジェットとの関係を確立するための特定の xtype があります。実装の観点から、これらのウィジェットは ExtJS フレームワークによってクライアント側でレンダリングされていました。
リソースタイプを作成したうえで、 sling:resourceType プロパティで作成したリソースタイプを参照して、新しいノードをダイアログに追加することによって、フィールドをインスタンス化できます。

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

コンポーネントのスタイル設定と動作を定義する場合は、カスタム CSS/LESS および JS を定義する専用の クライアントライブラリ を作成できます。
To have your client library loaded solely for your component dialog (i.e. it will not be loaded for another component) you need to set the property extraClientlibs ** **of your dialog to the category name of the client library you have just created. この方法は、クライアントライブラリが非常に大きい場合や、フィールドがそのダイアログに固有で、他のダイアログで必要になることがない場合にお勧めです。
クライアントライブラリをすべてのダイアログ用に読み込むには、クライアントライブラリのカテゴリプロパティを cq.authoring.dialog に設定します。これは、すべてのダイアログのレンダリング時にデフォルトで含まれるクライアントライブラリのカテゴリ名です。クライアントライブラリが小さい場合や、フィールドが汎用的で、他のダイアログで再利用できる場合には、この方法を使用できます。
例えば、次を参照してください。

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

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

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

レンダリング条件( rendercondition )を使用して、ダイアログ内の特定のタブやフィールドへのアクセス権を持つユーザーを制御することもできます。以下に例を示します。
+ mybutton
  - sling:resourceType = granite/ui/components/coral/foundation/button
  + rendercondition
    - sling:resourceType = myapp/components/renderconditions/group
    - groups = ["administrators"]

Handling Field Events

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

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

フィールドにロジックを挿入するには、以下を実行する必要があります。
  1. 対象となるフィールドを、指定された CSS クラス(フック​**)でマークします。
  2. クライアントライブラリ内で、その CSS クラス名に対してフックされる JS リスナーを定義します(これによって、カスタムロジックの範囲がそのフィールドのみに限定され、同じタイプの他のフィールドに影響を与えなくなります)。
これを実現するには、やり取りする、基になるウィジェットライブラリについて理解する必要があります。反応するイベントの識別については、 Coral UI ドキュメント を参照してくださいExtJS を使用して実行する必要があったプロセスと非常によく似ています。指定されたウィジェットのドキュメントページを探し、そのイベント API の詳細を確認してください。
例えば、次を参照してください。

コンテンツ構造のリスナー

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 コンポーネント(ウィジェットと同等)のフィールド検証は、 foundation-validation API を使用して実行します。 詳しくは、
例えば、次を参照してください。
  • cqgems/customizingfield/components/clientlibs/customizingfield/js/validations.js
  • /libs/cq/gui/components/authoring/dialog/clientlibs/dialog/js/validations.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
      • Value: the group that the related asset belongs to; for example, media
    • assetMimetype の下)で、次の手順をおこないます。
      • タイプ: String
      • 値:関連アセットの MIME タイプ(例: image/* /*)
    • droptarget の下)で、次の手順をおこないます。
      • タイプ: String
      • 値:ドロップターゲット(例: image
    • resourceType の下)で、次の手順をおこないます。
      • タイプ: String
      • Value: the related component resource; for example, 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 にあります
The automatic creation of component instances can now be configured easily within the UI when using Core Components and Editable Templates. See Creating Page Templates for more information about defining which components are automatically associated with given media types.

AEM Brackets 拡張の使用

AEM Brackets 拡張 は、AEM コンポーネントおよびクライアントライブラリを編集するためのスムーズなワークフローを提供します。この拡張は、 Brackets コードエディターをベースとしています。
この拡張には、次の機能があります。
  • 同期を容易にして(Maven や File Vault は不要)、開発者の効率を向上させるだけでなく、AEM に関する知識が限られたフロントエンド開発者もプロジェクトに参加できるようにします。
  • Provides some HTL support, the template language designed to simplify component development and increase security.
Brackets は、コンポーネントを作成するための推奨メカニズムです。Brackets は、クラシック UI 向けに設計された CRXDE Lite のコンポーネント作成機能の代わりになります。

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

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

cq:listener コードの移行

If you are migrating a project that was designed for the classic UI, then the cq:listener code (and component related clientlibs) might use functions that are specific to the classic UI (such as CQ.wcm.* ). 移行するには、タッチ操作対応 UI 用の同等のオブジェクトまたは関数を使用して、このようなコードを更新する必要があります。
プロジェクトをタッチ操作対応 UI に完全に移行する場合は、タッチ操作対応 UI に関連するオブジェクトや関数を使用するように、このようなコードを置き換える必要があります。
ただし、移行期間中にプロジェクトがクラシック UI とタッチ操作対応 UI の両方に対応する必要がある場合(通常のシナリオ)は、適切なオブジェクトを参照する別々のコードを区別するためのスイッチを実装する必要があります。
このスイッチメカニズムは、次のように実装できます。
if (Granite.author) {
    // touch UI
} else {
    // classic UI
}

コンポーネントのドキュメント化

開発者は、以下をすばやく把握できるようにコンポーネントドキュメントに簡単にアクセスしたいと考えます。
  • 説明
  • 使用目的
  • コンテンツの構造とプロパティ
  • 公開済みの API と拡張ポイント
  • その他
この理由から、既存のドキュメントマークダウンをコンポーネント自体の中で利用できるようにすることは非常に簡単です。
これには、コンポーネント構造に README.md ファイルを配置するだけです。その後、このマークダウンは コンポーネントコンソール に表示されるようになります。
The supported markdown is the same as that for content fragments .