AEM の中心概念 aem-core-concepts

AEMでの開発の前提条件 prerequisites-for-developing-on-aem

AEM上での開発には、次のスキルが必要になります。

ガイドラインおよびベストプラクティス を読み、手順に従うこともお勧めします。

Java コンテンツリポジトリー java-content-repository

Java コンテンツリポジトリー（JCR）の規格である JSR 283 では、コンテンツリポジトリー内で、任意の精度レベルでコンテンツに双方向アクセスするための、ベンダーにも実装にも依存しない方法が指定されています。

仕様を主導しているのは、Adobe Research（スイス）AG です。

JCR API 2.0 パッケージ、javax.jcr。「*」は、リポジトリコンテンツの直接アクセスと操作に使用されます。

Experience Server(CRX) と Jackrabbit experience-server-crx-and-jackrabbit

Experience Server は、AEMが構築され、カスタムアプリケーションの構築に利用できる Experience Services を提供し、Jackrabbit に基づいてコンテンツリポジトリを埋め込みます。

Apache Jackrabbit は、JCR API 2.0 の完全準拠のオープンソース実装です。

Sling のリクエスト処理 sling-request-processing

Sling の概要 introduction-to-sling

AEM の構築には Sling が使用されています。これは、REST の原則に基づき、コンテンツ指向のアプリケーションを容易に開発できる Web アプリケーションフレームワークです。Sling は、データストアとして、Apache Jackrabbit のような JCR リポジトリー、または AEM の場合は CRX Content Repository を使用します。Sling は Apache Software Foundation に寄贈されました。詳細に関しては Apache をご覧ください。

Sling を使用する場合、レンダリングされるコンテンツのタイプは、処理に関する第一の考慮事項ではありません。主な考慮事項は、URL を解決して得られるコンテンツオブジェクト用に、レンダリングを実行するためのスクリプトが見つかるかどうかです。このことは、要件に合わせて簡単にカスタマイズ可能なページを Web コンテンツ作成者が構築する際に非常に役立ちます。

この柔軟性の利点は、様々なコンテンツ要素を持つアプリ、または容易にカスタマイズできるページが必要な場合に明らかです。特に、WCM などの Web コンテンツ管理システムをAEMソリューションに実装する場合。

Sling を使用した開発の概要について詳しくは、『15 分間でわかる Sling』を参照してください。

次の図は、Sling のスクリプト解決の説明です。HTTP リクエストからコンテンツノード、コンテンツノードからリソースタイプ、リソースタイプからスクリプトを得る方法と、使用可能なスクリプト変数を示しています。

次の図は、SlingPostServlet を扱う際に使用できる、非表示ながらも強力なリクエストパラメータをすべて説明しています。これは、すべての POST リクエストのデフォルトハンドラで、リポジトリー内のノードの作成、変更、削除、コピー、移動に無限のオプションを提供します。

Sling はコンテンツ中心型 sling-is-content-centric

Sling は コンテンツ中心型 です。これは、各（HTTP）リクエストが JCR リソース（リポジトリーノード）の形でコンテンツにマッピングされるため、コンテンツに焦点を当てた処理が行われることを意味します。

RESTful Sling restful-sling

コンテンツ中心の考え方により、Sling は REST 指向のサーバーを実装するので、Web アプリケーションフレームワークに新しい概念を備えています。 メリットは次のとおりです。

URL の分解 url-decomposition

Sling では、処理はユーザーリクエストの URL によって駆動されます。これにより、適切なスクリプトによって表示されるコンテンツが定義されます。これを行うために、URL から情報が抽出されます。

次の URL を分析する場合：

https://myhost/tools/spy.printable.a4.html/a/b?x=12

次のような複合部品に分割できます。

プロトコル - HTTP

ホスト - web サイトの名前。

コンテンツのパス - レンダリングされるコンテンツを指定するパス。拡張機能と組み合わせて使用します。この例では、tools/spy.html に変換します。

セレクター - コンテンツをレンダリングする方法を選ぶために使用します。この例では、A4 形式のプリンターに対応したバージョンを選択しています。

拡張子 - コンテンツの形式。これも、レンダリングに使用するスクリプトを指定します。

サフィックス - 追加情報を指定するために使用できます。

パラメーター - 動的コンテンツで必要なパラメーターです。

URL からコンテンツおよびスクリプトへ from-url-to-content-and-scripts

次の原則を使用します。

次の図は、使用するメカニズムを示しています。このメカニズムについては、以降の節で詳しく説明します。

Sling を使用して、特定のエンティティをレンダリングするスクリプトを指定します（JCR ノードで sling:resourceType プロパティを設定します）。このメカニズムは、リソースが複数のレンディションを持つことができるため、スクリプトがデータエンティティにアクセスするメカニズム（PHP スクリプトの SQL 文のように）よりも自由度が高くなります。

リソースへのリクエストのマッピング mapping-requests-to-resources

リクエストを分解し、必要な情報を抽出します。リポジトリーで、リクエストされたリソース（コンテンツノード）を検索します。

Sling では JCR 以外のノードもリソースとして扱えますが、これは詳細な機能です。

スクリプトの検索 locating-the-script

適切なリソース（コンテンツノード）が見つかると、sling リソースタイプ ​が抽出されます。これは、コンテンツのレンダリングに使用するスクリプトを見つけるパスです。

sling:resourceType によって指定されるパスは、次のいずれかです。

Sling のスクリプトはすべて、/apps または /libs のサブフォルダーに格納され、この順序で検索されます（コンポーネントおよびその他の要素のカスタマイズを参照）。

その他の注意点は次のとおりです。

AEM の特定のインスタンスでサポートされているスクリプトエンジンのリストは、Felix Management Console（http://<host>:<port>/system/console/slingscripting）にあります。

また、Apache Sling では、他の一般的なスクリプトエンジン（Groovy、JRuby、Freemarker など）との統合がサポートされており、新しいスクリプトエンジンと統合する方法も提供されています。

前述の例を使用すると、sling:resourceType が hr/jobs の場合は、次のようになります。

特定のリクエストに複数のスクリプトが該当する場合は、一致率が最も高いスクリプトが選択されます。一致は具体的であるほど良くなります。つまり、リクエスト拡張子であれ、メソッド名の一致であれ、セレクターの一致が多いほど良くなります。

例えば、次のリソースにアクセスするためのリクエストについて考えます。
/content/corporate/jobs/developer.print.a4.html
リソースのタイプは次のとおりとします。
sling:resourceType="hr/jobs"

また、次のリストのスクリプトが正しい場所にあると仮定します。

この場合、優先順位は (8) - (7) - (6) - (5) - (4) - (3) - (2) - (1) となります。

リソースタイプ（主に sling:resourceType プロパティで定義）に加えて、リソーススーパータイプもあります。これは通常、sling:resourceSuperType プロパティで示されます。これらのスーパータイプは、スクリプトを検索する際にも検討されます。リソーススーパータイプの利点は、（デフォルトのサーブレットで使用される）デフォルトのリソースタイプ sling/servlet/default が事実上のルートになるリソースの階層を形成できる点です。

リソースのリソーススーパータイプは次の 2 つの方法で定義できます。

次に例を示します。

タイプの階層は

これは、/y には sling:resourceSuperType プロパティがあるのに対して、/x にはなく、スーパータイプがリソースタイプから継承されているからです。

Sling スクリプトを直接呼び出すことはできません sling-scripts-cannot-be-called-directly

Sling 内では、スクリプトを直接呼び出すことはできません。これは、REST サーバーの厳密な概念を破るからです。リソースと表示域を混在させることができます。

表現（スクリプト）を直接呼び出す場合、スクリプト内のリソースを非表示にするので、フレームワーク (Sling) はそれを認識しません。 そのため、次の特定の機能が失われます。

Sling API sling-api

これは、Sling API パッケージ、org.apache.sling.*、およびタグライブラリを使用します。

sling:include を使用した既存の要素の参照 referencing-existing-elements-using-sling-include

最後の考慮事項は、スクリプト内にある既存の要素の参照の必要性です。

より複雑なスクリプト（集計スクリプト）は、複数のリソース（ナビゲーション、サイドバー、フッター、リストの要素など）へのアクセスが必要になる場合があり、そのために​ リソース ​を含めます。

これは、sling:include("/<path>/<resource>") コマンドを使用して行えます。これにより、参照されるリソースの定義を効率的に含めることができます。例えば、次のステートメントでは、画像をレンダリングするために既存の定義を参照しています。

%><sling:include resourceType="geometrixx/components/image/img"/><%

OSGi osgi

OSGi は、モジュラー型アプリケーションおよびライブラリを開発およびデプロイするためのアーキテクチャを定義します（Java 用 Dynamic Module System とも呼ばれます）。 OSGi コンテナを使用すると、アプリケーションを個々のモジュール（追加のメタ情報を含む jar ファイルで、OSGi 用語でバンドルと呼ばれます）に分割し、それらの間の相互依存関係を次の機能で管理できます。

これらのサービスと契約は、個々の要素が相互に動的に検出して共同作業を行うためのアーキテクチャを提供します。

OSGi フレームワークは、再起動を必要とせずに、これらのバンドルの動的な読み込み/アンロード、設定および制御を提供します。

このアーキテクチャにより、Sling をアプリケーション固有のモジュールで拡張できます。Sling、つまり CQ5 は、 Apache Felix OSGI（Open Services Gateway イニシアチブ）の実装であり、OSGi Service Platform リリース 4 バージョン 4.2 仕様に基づいています。 どちらも、OSGi フレームワーク内で実行される OSGi バンドルの集まりです。

これにより、インストール内のどのパッケージでも、以下のアクションを実行できます。

詳しくは、Web コンソール、OSGI 設定、および OSGi 設定の指定を参照してください。

AEM環境の開発オブジェクト development-objects-in-the-aem-environment

開発に関しては、次の点が重要です。

項目 - ノードまたはプロパティのアイテム。

項目オブジェクトの操作方法について詳しくは、Interface javax.jcr Item の Javadocs を参照してください。

ノード（およびそのプロパティ） - ノードとそのプロパティは、JCR API 2.0 仕様（JSR 283）で定義されています。コンテンツ、オブジェクト定義、レンダリングスクリプトおよびその他のデータを格納します。

ノードはコンテンツ構造を定義し、そのプロパティには実際のコンテンツとメタデータが格納されます。

コンテンツノードがレンダリングを駆動します。 Sling は、受信リクエストからコンテンツノードを取得します。 このノードの sling:resourceType プロパティは、使用する Sling レンダリングコンポーネントを指します。

JCR 名であるノードは、Sling 環境ではリソースとも呼ばれます。

例えば、現在のノードのプロパティを取得するには、スクリプトで次のコードを使用できます。

PropertyIterator properties = currentNode.getProperties();

currentNode は現在のノードオブジェクトです。

ノードオブジェクトの操作方法について詳しくは、Javadocs を参照してください。

Widget - AEMでは、すべてのユーザー入力はウィジェットで管理されます。多くの場合、コンテンツの一部の編集を制御するために使用されます。

ダイアログはウィジェットを組み合わせて作成します。

AEMは、ウィジェットの ExtJS ライブラリを使用して開発されました。

ダイアログ - ダイアログは特殊なタイプのウィジェットです。

コンテンツを編集するために、AEMはアプリケーション開発者が定義したダイアログを使用します。 一連のウィジェットを組み合わせて、関連するコンテンツの編集に必要なすべてのフィールドとアクションをユーザーに表示します。

ダイアログは、メタデータの編集や、様々な管理ツールでも使用されます。

コンポーネント - ソフトウェアコンポーネントは、事前に定義されたサービスやイベントを提供するシステム要素であり、他のコンポーネントと通信できます。

AEM内では、多くの場合、リソースのコンテンツをレンダリングするためにコンポーネントが使用されます。 リソースがページの場合、レンダリングされるコンポーネントはトップレベルコンポーネントまたはページコンポーネントと呼ばれます。 ただし、コンポーネントは、コンテンツをレンダリングしたり、特定のリソースにリンクしたりする必要はありません。例えば、ナビゲーションコンポーネントには、複数のリソースに関する情報が表示されます。

コンポーネントの定義には、以下が含まれます。

テンプレート - テンプレートは特定のタイプのページのベースとなります。「Web サイト」タブでページを作成する際は、ユーザーはテンプレートを選択する必要があります。このテンプレートをコピーして新しいページが作成されます。

テンプレートは、作成するページと同じ構造を持ち、実際のコンテンツを持たないノードの階層です。

ページとデフォルトコンテンツ（プライマリトップレベルコンテンツ）のレンダリングに使用するページコンポーネントを定義します。 コンテンツは、AEMがコンテンツ中心型としてレンダリングされる方法を定義します。

ページコンポーネント（トップレベルコンポーネント） - ページのレンダリングに使用するコンポーネント。

ページ - ページはテンプレートの「インスタンス」です。

ページには、タイプが cq:Page の階層ノードと、タイプが cq:PageContent のコンテンツノードがあります。 コンテンツノードの sling:resourceType プロパティは、ページのレンダリングに使用されるページコンポーネントを指します。

例えば、現在のページの名前を取得するには、スクリプトで次のコードを使用できます。

String pageName = currentPage.getName();

currentPage は現在のページオブジェクトです。ページオブジェクトの操作方法について詳しくは、Javadocs を参照してください。

ページマネージャー - ページマネージャーは、ページレベルの操作方法を提供するインターフェイスです。

例えば、リソースの含まれるページを取得するには、スクリプトで次のコードを使用できます。

Page myPage = pageManager.getContainingPage(myResource);

pageManager はページマネージャーオブジェクト、myResource はリソースオブジェクトです。ページマネージャーで提供される方法について詳しくは、Javadocs を参照してください。

リポジトリー内の構造 structure-within-the-repository

次のリストは、リポジトリー内で見られる構造の概要です。

環境 environments

AEMを使用した実稼動環境は、多くの場合、2 つの異なるタイプのインスタンスで構成されます。an オーサーインスタンスとパブリッシュインスタンス.

Dispatcher the-dispatcher

Dispatcher は、キャッシュとロードバランシングの両方をAdobeに提供するツールです。 詳しくは、 Dispatcher.

FileVault （ソースリビジョンシステム） filevault-source-revision-system

FileVault は、JCR リポジトリにファイルシステムマッピングとバージョン管理を提供します。 標準のバージョン管理システム（Subversion など）で、プロジェクトコード、コンテンツ、設定などの保存とバージョン管理を完全にサポートして、AEM開発プロジェクトを管理するために使用できます。

詳しくは、 FileVault ツール 詳しくは、ドキュメントを参照してください。

workflows workflows

多くの場合、コンテンツは組織のプロセスに依存します。これには、様々な参加者による承認やサインオフの手順が含まれます。 これらのプロセスは、ワークフローとして表すことができます。 AEM内で定義および開発されるを 適切なコンテンツページ または デジタルアセット 必要に応じて。

ワークフローエンジンは、ワークフローの実装と、その後のコンテンツへの適用を管理するために使用されます。

マルチサイト管理 multi-site-management

マルチサイトマネージャー (MSM) を使用すると、共通のコンテンツを共有する複数の Web サイトを簡単に管理できます。 MSM では、サイト間の関係を定義して、あるサイトでのコンテンツの変更が他のサイトに自動的にレプリケートされるようにすることができます。

例えば、Web サイトは、多くの場合、国際的なオーディエンス向けに複数の言語で提供されています。 同じ言語のサイト数が少ない場合（3～5 個）、サイト間でコンテンツを同期する手動プロセスが可能です。 ただし、サイトの数が増えるか、複数の言語が関わる場合は、すぐにプロセスを自動化する方が効率的になります。

詳しくは、 マルチサイトマネージャ.