現在表示中:

AEM での開発の必要条件

AEM での開発には、以下のスキルが必要です。

  • 以下を含む Web アプリケーション技術の基本知識
    • リクエスト - 応答(XMLHttpRequest/XMLHttpResponse)のサイクル
    • HTML
    • CSS
    • JavaScript
  • Content Explorer を含む Experience Server(CRX)の実務知識
  • クラシック UI で開発する場合は、JSP の簡単な例を理解および変更できる能力を含む、JSP(JavaServer Pages)の基本知識が必要です。

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

Java コンテンツリポジトリ

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

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

JCR API 2.0 パッケージである javax.jcr.* が、リポジトリコンテンツの直接アクセスおよび操作用に使用されます。

Experience Server(CRX)と Jackrabbit

Experience Server は、AEM の基でありカスタムアプリケーションの構築に活用できる Experience Services を備えており、Jackrabbit に基づいてコンテンツリポジトリを埋め込みます。

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

Sling のリクエスト処理

Sling の概要

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

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

この柔軟性のメリットは、アプリケーションに幅広い様々なコンテンツ要素が含まれる場合や、簡単にカスタマイズできるページが必要な場合に明らかです。特に、WCM のような Web コンテンツ管理システムを AEM ソリューションに実装する場合です。

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

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

chlimage_1

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

chlimage_1

Sling はコンテンツ中心型

Sling はコンテンツ中心型です。つまり、(HTTP)リクエストがそれぞれ JCR リソース(リポジトリノード)の形式でコンテンツにマップされるので、コンテンツに焦点を当てた処理がおこなわれるということです。

  • 最初のターゲットは、コンテンツを保持しているリソース(JCR ノード)です。

  • 次に、表現、つまりスクリプトが、リソースプロパティから、リクエストの一部(セレクターや拡張子など)と組み合わせて配置されます。

RESTful Sling

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

  • 表面上だけでなく、非常に RESTful であり、リソースや表現をサーバー内で正しくモデリング

  • 1 つ以上のデータモデルを削除

    • 以前に必要だったもの:URL 構造、ビジネスオブジェクト、DB スキーマ

    • 現在必要なもの:URL = リソース = JCR 構造

URL の分解

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

次の URL を分析する場合、

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

以下の複合部分に分割できます。

プロトコル ホスト コンテンツのパス セレクター 拡張子   サフィックス   パラメーター 
http:// myhost tools/spy .printable.a4. html / a/b ? x=12

プロトコル

HTTP

ホスト

Web サイトの名前。

コンテンツのパス

レンダリングされるコンテンツを指定するパス。拡張子と共に使用します。この例では、tools/spy.html に変換されます。

セレクター

コンテンツのレンダリングの代替方法として使用します。この例では、A4 形式のプリンターに対応するバージョンです。

拡張子

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

サフィックス

追加情報を指定するために使用できます。

パラメーター

動的コンテンツに必要なパラメーター。

URL からコンテンツおよびスクリプトへ

これらの原則を使用して、

  • マッピングはリクエストから抽出されたコンテンツパスを使用してリソースを見つけます。

  • 適切なリソースが見つかると、Sling リソースタイプが抽出され、コンテンツのレンダリングに使用するスクリプトを見つけるために使用されます。

下の図は、使用するメカニズムを示しています。これについては、以下の各項で詳細に説明します。

chlimage_1

Sling を使用して、一定のエンティティをどのスクリプトがレンダリングするかを指定します(JCR ノードで sling:resourceType プロパティを設定)。このメカニズムでは、1 つのリソースで複数のレンディションが可能なので、スクリプトがデータエンティティにアクセスするメカニズム(PHP スクリプト内の SQL ステートメントなど)よりも自由度が高くなります。

リソースへのマッピングリクエスト

リクエストは分解され、必要な情報が抽出されます。リポジトリで、リクエストされたリソース(コンテンツノード)の検索がおこなわれます。

  • 最初の Sling では、リクエストで指定されている場所(例:../content/corporate/jobs/developer.html)にノードが存在するかどうかを確認します。

  • ノードが見つからない場合は、拡張子をドロップして検索を繰り返します(例:../content/corporate/jobs/developer)。

  • それでもノードが見つからない場合、Sling は HTTP コード 404(Not Found)を返します。

Sling では JCR ノード以外のものをリソースとすることもできますが、これは高度な機能です。

スクリプトの検索

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

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

  • 絶対パス
  • 設定パラメーターに対する相対パス
    移植性向上のために、相対パスをお勧めします。

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

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

  • メソッド(GET、POST)が必要なときは、HTTP の仕様に従って大文字で指定します(例:jobs.POST.esp。以下を参照)。
  • 以下のような様々なスクリプトエンジンがサポートされています。
    • .esp、.ecma:ECMAScript(JavaScript)Pages(サーバー側実行)
    • .jsp:Java Server Pages(サーバー側実行)
    • .java:Java Servlet Compiler(サーバー側実行)
    • .jst:JavaScript テンプレート(クライアント側実行)

CQ の特定のインスタンスでサポートされているスクリプトエンジンのリストは、Felix Management Console(http://localhost:4502/system/console/config/slingscripting.txt)にあります。

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

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

  • GET/HEAD リクエスト、および .html で終わる URL(デフォルトのリクエストタイプ、デフォルトの形式)
    スクリプトは /apps/hr/jobs/jobs.esp となり、sling:resourceType の最後のセクションがファイル名を形成します。
  • POST リクエスト(GET/HEAD を除くすべてのリクエストタイプ、メソッド名は大文字表記)
    POST がスクリプト名で使用されます。
    スクリプトは /apps/hr/jobs/jobs.POST.esp となります。
  • .html で終わらない、他の形式の URL
    例えば、../content/corporate/jobs/developer.pdf などです。
    スクリプトは /apps/hr/jobs/jobs.pdf.esp となり、サフィックスがスクリプト名に追加されます。
  • セレクターを含む URL
    セレクターを使用すると、同じコンテンツを別の形式で表示できます。例えば、プリンター対応バージョン、RSS フィード、概要などです。
    プリンター対応バージョンで、セレクターが print の場合(../content/corporate/jobs/developer.print.html など)は、
    スクリプトは /apps/hr/jobs/jobs.print.esp となり、セレクターがスクリプト名に追加されます。
  • sling:resourceType が定義されていない場合は、次のようになります。
    • コンテンツパスを使用して適切なスクリプトが検索されます(パスベースの ResourceTypeProvider がアクティブな場合)。
      例えば、../content/corporate/jobs/developer.html のスクリプトによって、/apps/content/corporate/jobs/ 内で検索が生成されます。
    • プライマリノードタイプが使用されます。
  • スクリプトがまったく見つからない場合は、デフォルトのスクリプトが使用されます。
    デフォルトのレンディションは、現在はプレーンテキスト(.txt)、HTML(.html)および JSON(.json)としてサポートされており、そのすべてでノードのプロパティが(適切な書式で)リストされます。拡張子 .res のデフォルトのレンディション、またはリクエスト拡張子のないリクエストは、リソースをスプールするためのものです(可能な場合)。
  • HTTP エラー処理(コード 403 または 404)の場合、Sling は以下のいずれかの場所でスクリプトを検索します。

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

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

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

  1. GET.esp
  2. jobs.esp
  3. html.esp
  4. print.esp
  5. print.html.esp
  6. print/a4.esp
  7. print/a4/html.esp
  8. print/a4.html.esp

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

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

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

  • リソースの sling:resourceSuperType プロパティを使用。
  • sling:resourceType が示すノードの sling:resourceSuperType プロパティを使用。

次に例を示します。

  • /
    • a
    • b
      • sling:resourceSuperType = a
    • c
      • sling:resourceSuperType = b
    • x
      • sling:resourceType = c
    • y
      • sling:resourceType = c
      • sling:resourceSuperType = a

/x のタイプ階層は [ c, b, a, <default>] で、/y の階層は [ c, a,<default>] です。これは、/y には sling:resourceSuperType プロパティがあるのに対して、/x にはなく、スーパータイプがリソースタイプから継承されているからです。

Sling スクリプトを直接呼び出しできない

Sling 内では、スクリプトを直接呼び出しできません。REST サーバーの厳格な概念に違反して、リソースと表現を混在させることになるからです。

表現(スクリプト)を直接呼び出す場合、リソースがスクリプト内に隠され、フレームワーク(Sling)では認識できなくなります。これにより、次のような機能が失われます。

  • GET 以外の HTTP メソッドの自動処理。これには以下が含まれます。

    • Sling のデフォルトの実装で処理される POST、PUT、DELETE

    • sling:resourceType 内の POST.jsp スクリプト

  • コードアーキテクチャに必要なクリーン性や明確な構造が失われます。これは大規模な開発では最も重要です。

Sling API

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

sling:include を使用した既存の要素の参照

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

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

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

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

OSGI

OSGi は、モジュール式アプリケーションおよびライブラリを開発およびデプロイするためのアーキテクチャを定義します(Dynamic Module System for Java とも言う)。OSGi コンテナを使用すると、アプリケーションを個々のモジュール(追加のメタ情報を含む jar ファイルで、OSGi 用語ではバンドル)に分解し、以下を使用してモジュール間の相互依存性を管理できます。

  • コンテナ内に実装されているサービス
  • コンテナとアプリケーションの間の契約

これらのサービスおよび契約によって提供されるアーキテクチャでは、コラボレーションのために個々の要素が相互に動的に検出し合うことができます。

その後、OSGi フレームワークによって、これらのバンドルの動的読み込み/読み込み解除、設定および制御が可能になります。再起動は不要です。

注意:

OSGi テクノロジーについて詳しくは、OSGi Alliance のテクノロジーの概要を参照してください。

特に、基礎教育に関するページには、プレゼンテーションやチュートリアルのコレクションが収められています。

このアーキテクチャを使用すると、アプリケーション専用のモジュールで Sling を拡張できます。Sling、そして CQ5 は、Apache Felix 実装の OSGI(Open Services Gateway initiative)を使用しており、OSGi Service Platform Release 4 バージョン 4.2 の仕様に基づいています。いずれも、OSGi フレームワーク内で動作している OSGi バンドルのコレクションです。

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

  • インストール
  • 開始
  • 停止
  • 更新
  • アンインストール
  • 現在のステータスの確認
  • 特定のバンドルに関する詳細情報(記号名、バージョン、場所など)へのアクセス

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

AEM 環境の開発オブジェクト

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

項目

項目(item)とは、ノードまたはプロパティのことです。

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

ノード(およびそのプロパティ)

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

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

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

ノードというのは JCR 名であり、Sling 環境ではリソースとも呼びます。

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

    PropertyIterator properties = currentNode.getProperties();

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

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

ウィジェット

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

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

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

ダイアログ

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

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

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

コンポーネント

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

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

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

  • コンテンツのレンダリングに使用するコード

  • ユーザー入力および結果コンテンツの設定のためのダイアログ

テンプレート

テンプレートとは、特定のタイプのページの基礎です。「Web サイト」タブでページを作成するとき、ユーザーはテンプレートを選択する必要があります。その後、このテンプレートをコピーすることによって新しいページが作成されます。

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

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

ページコンポーネント(トップレベルコンポーネント)

ページのレンダリングに使用するコンポーネント。

ページ

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

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

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

String pageName = currentPage.getName();

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

ページマネージャー

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

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

Page myPage = pageManager.getContainingPage(myResource);

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

リポジトリ内の構造

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

警告:

この構造、またはその中のファイルの変更は、注意しておこなう必要があります。

変更は、開発の際に必要になりますが、変更がどのような意味を持つかを完全に理解しておく必要があります。

警告:

/libs パス内では何も変更しないでください。設定その他を変更する場合は、/libs から /apps へ項目をコピーして、/apps 内で変更をおこないます。

  • /apps
    関連するアプリケーション。Web サイト専用のコンポーネント定義を含みます。コンポーネントを開発する際は、/libs/foundation/components にある、そのまま使用できるコンポーネントをベースとして使用できます。
  • /content
    Web サイト用に作成されたコンテンツ。
  • /etc
    詳しくは、ツールに関する節を参照してください。
  • /home
    ユーザーおよびグループの情報。
  • /libs
    AEM のコアに所属するライブラリおよび定義。/libs 内のサブフォルダーは、search(検索)や replication(レプリケーション)など、AEM のそのまま使用できる機能を表します。/libs の内容は、AEM の動作に影響するので、変更しないでください。Web サイト専用の機能は、/apps の下で開発する必要があります(コンポーネントおよびその他の要素のカスタマイズを参照)。
  • /tmp
    一時作業領域。
  • /var
    監査ログ、統計、イベント処理など、変更やシステムによる更新がおこなわれるファイル。サブフォルダーである /var/classes には、Java サーブレットが、コンポーネントのスクリプトから生成されたソースおよびコンパイル形式で含まれます。

環境

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

Dispatcher

Dispatcher は、キャッシュとロードバランシングのいずれかまたは両方に対応するアドビのツールです。詳しくは、Dispatcher を参照してください。

FileVault(ソースリビジョンシステム)

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

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

ワークフロー

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

 

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

マルチサイト管理

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

例えば、Web サイトは多くの場合、世界中の閲覧者に対応するように、複数の言語で提供されます。同じ言語のサイト数が少ない(3 ~ 5 個)場合は、手動による処理でも、サイトをまたがってコンテンツを同期できます。ただし、サイト数が増えた場合や、複数の言語が関連する場合は、プロセスを自動化したほうが効率的になります。

  • 様々な言語バージョンの Web サイトを効率的に管理します。
  • ソースサイトに基づいて 1 つ以上のサイトを自動的に更新します。
    • 基本構造を共通にして、複数のサイトで共通のコンテンツを使用します。
    • 利用可能なリソースを最大限に使用します。
    • 共通のルックアンドフィールを維持します。
    • サイト間で異なるコンテンツの管理に労力を集中させます。
詳しくは、マルチサイトマネージャーを参照してください。

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

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