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 は、コンテンツ指向アプリケーションの開発を容易にする REST 原則に基づく web アプリケーションフレームワーク Sling を使用して構築されています。Sling はデータストアとして、Apache Jackrabbit のような JCR リポジトリ、または、AEM の場合は CRX コンテンツリポジトリを使用します。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 は、OSGI（Open Services Gateway initiative）の Apache Felix 実装を使用しており、OSGi Service Platform Release 4 バージョン 4.2 の仕様に基づいています。どちらも、OSGi フレームワーク内で実行される OSGi バンドルの集まりです。

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

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

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

開発の際に関心事となるものを以下に示します。

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

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

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

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

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

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

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

PropertyIterator properties = currentNode.getProperties();

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

Node オブジェクトの操作方法について詳しくは、Java™ docs を参照してください。

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

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

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

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

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

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

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

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

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

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

テンプレートは、そこから作成されるページと同じ構造を持つノード階層ですが、実際のコンテンツは含みません。

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

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

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

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

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

String pageName = currentPage.getName();

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

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

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

Page myPage = pageManager.getContainingPage(myResource);

pageManager はページマネージャーオブジェクトで、myResource はリソースオブジェクトです。ページマネージャーが提供するメソッドについて詳しくは、Java™ docs を参照してください。

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

以下のリストは、リポジトリ内で見られる構造の概要を示しています。

環境 environments

AEM では、実稼働環境は多くの場合、オーサーインスタンスとパブリッシュインスタンスという 2 種類のインスタンスで構成されます。

Dispatcher the-dispatcher

Dispatcher は、キャッシュとロードバランシングの両方を管理するアドビのツールです。詳しくは、Dispatcher を参照してください。

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

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

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

ワークフロー workflows

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

ワークフローエンジンを使用して、ワークフローの実装と、その後のコンテンツへの適用を管理します。

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

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

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

詳しくは、マルチサイトマネージャーを参照してください。