ソーシャルコンポーネントフレームワーク

ソーシャルコンポーネントフレームワーク（SCF）によって、サーバー側とクライアント側の両方で、コミュニティコンポーネントの設定、カスタマイズおよび拡張のプロセスが簡素化されます。

フレームワークの利点：

  • 機能:80%の使用例に対してカスタマイズがほとんどあるいはまったくない状態で、すぐに使用できる簡単な統合。
  • スキン可能:CSSスタイル設定でのHTML属性の一貫した使用。
  • 拡張可能:コンポーネントの実装は、オブジェクト指向でビジネスロジックが軽量で、サーバー上に増分的なビジネスログインを簡単に追加できます。
  • 柔軟性:簡単にオーバーレイおよびカスタマイズできる、ロジックがない単純なJavaScriptテンプレート。
  • アクセス可能:HTTP APIは、モバイルアプリを含む任意のクライアントからの投稿をサポートします。
  • ポータブル:任意のテクノロジーで構築されたWebページに統合/埋め込みを行う。

インタラクティブなコミュニティコンポーネントガイドを使用して、オーサーまたはパブリッシュインスタンスについて確認してください。

概要

SCF では、コンポーネントは SocialComponent POJO、Handlebars JS テンプレート（コンポーネントをレンダリングするため）および CSS（コンポーネントのスタイルを設定するため）で構成されます。

Handlebars JS テンプレートでは、モデル／ビュー JS コンポーネントを拡張して、クライアントでのコンポーネントとのユーザーインタラクションを処理できます。

コンポーネントがデータの変更をサポートする必要がある場合は、従来の Web アプリケーションでのモデル／データオブジェクトと同様のデータの編集／保存をサポートするために、SocialComponent API の実装を記述できます。さらに、操作リクエストの処理、ビジネスロジックの実行、モデル/データオブジェクトでのAPIの呼び出しを行うために、操作（コントローラー）と操作サービスを追加できます。

クライアントが必要とするデータをビューレイヤーまたは HTTP クライアントに提供するために、SocialComponent API を拡張できます。

クライアントに対するページのレンダリング方法

scf-page-rendering

コンポーネントのカスタマイズおよび拡張

コンポーネントをカスタマイズまたは拡張するには、今後のリリースへのアップグレードプロセスを簡素化する /apps ディレクトリに対してオーバーレイおよび拡張のみを記述します。

  • スキニングの場合：
  • ルックアンドフィール：
    • JSテンプレートとCSSを変更します。
  • ルックアンドフィール&UX向け：
    • JSテンプレート、CSSおよびJavaScriptの拡張/オーバーライドを変更します。
  • JSテンプレートまたはGETエンドポイントで使用可能な情報を変更するには：
  • 操作中にカスタム処理を追加するには：
  • 新しいカスタム操作を追加するには：
    • 新しいSling Post操作を作成します。
    • 必要に応じて、既存のOperationServicesを使用します。
    • 必要に応じてクライアント側から操作を呼び出すJavaScriptコードを追加します。

サーバー側フレームワーク

このフレームワークでは、サーバー上の機能にアクセスし、クライアントとサーバー間のインタラクションをサポートするための API が提供されます。

Java API

Java API では、継承またはサブクラス化が容易な抽象クラスおよびインターフェイスが提供されます。

メインクラスについては、サーバー側のカスタマイズページで説明します。

UGCの使用については、「 ストレージリソースプロバイダーの概要 」を参照してください。

HTTP API

HTTP API によって、PhoneGap アプリ、ネイティブアプリ、その他の統合およびマッシュアップについて、カスタマイズの容易さとクライアントプラットフォームの選択がサポートされます。さらに、HTTP APIを使用すると、コミュニティサイトをクライアントなしでサービスとして実行できるので、フレームワークコンポーネントを任意のテクノロジーで構築されたWebページに統合できます。

HTTP API - GET 要求

すべての SocialComponent に対して、フレームワークによって HTTP ベースの API エンドポイントが提供されます。このエンドポイントにアクセスするには、「.social.json」セレクターと拡張子を持つGETリクエストをリソースに送信します。 Slingを使用して、要求がDefaultSocialGetServletに渡されます。

DefaultSocialGetServlet

  1. リソース(resourceType)をSocialComponentFactoryManagerに渡し、リソースを表すSocialComponentを選択できるSocialComponentFactoryを受け取ります。

  2. ファクトリを呼び出し、リソースとリクエストを処理できるSocialComponentを受け取ります。

  3. SocialComponentを呼び出し、要求を処理して結果のJSON表現を返します。

  4. JSONレスポンスをクライアントに返します。

GET Request

デフォルトの GET Servlet が、SocialComponent がカスタマイズ可能な JSON で応答する .social.json 要求をリスニングします。

scf-framework

HTTP API - POST 要求

GET（読み取り）操作に加え、コンポーネントに対するその他の操作（作成、更新、削除など）を可能にするエンドポイントパターンがフレームワークによって定義されます。これらのエンドポイントは、HTTPステータスコードまたはJSON応答オブジェクトを使用して入力を受け取り、応答するHTTP APIです。

このフレームワークエンドポイントパターンにより、CUD 操作は拡張、再利用およびテストが可能になります。

POST Request

SocialComponent 操作ごとに Sling POST :operation があります。各操作のビジネスロジックとメンテナンスコードは、HTTP APIを通じて、またはOSGiサービスとして他の場所からアクセスできるOperationServiceにラップされます。 前後のアクションに対してプラグ可能な操作拡張をサポートするフックが提供されます。

scf-post-request

ストレージリソースプロバイダー（SRP）

コミュニティコンテンツストアに格納された UGC の処理については、以下を参照してください。：

サーバー側のカスタマイズ

サーバー側のコミュニティコンポーネントのビジネスロジックおよび動作のカスタマイズについて詳しくは、サーバー側のカスタマイズを参照してください。

Handlebars JS テンプレート言語

新しいフレームワークの顕著な変更の1つは、サーバーとクライアントのレンダリングに一般的なオープンソーステクノロジーであるHandlebars JS(HBS)テンプレート言語の使用です。

HBS スクリプトは、単純で、ロジックがなく、サーバーとクライアントの両方でコンパイルされ、オーバーレイやカスタマイズが容易であり、HBS ではクライアント側のレンダリングがサポートされているのでクライアント UX と自然にバインドします。

このフレームワークでは、SocialComponent の開発に便利な複数の Handlebars ヘルパーが提供されます。

サーバーで、Sling は GET 要求を解決するときに、要求への応答に使用されるスクリプトを識別します。スクリプトがHBSテンプレート(.hbs)の場合、Slingは要求をHandlebarsエンジンにデリゲートします。 次に、Handlebars Engineは、適切なSocialComponentFactoryからSocialComponentを取得し、コンテキストを構築して、HTMLをレンダリングします。

アクセス制限なし

Handlebars（HBS）テンプレートファイル（.hbs）は、.jsp および .html テンプレートファイルに似ていますが、クライアントブラウザーとサーバーの両方でレンダリングに使用できる点が異なります。そのため、クライアント側テンプレートを要求するクライアントブラウザーは、.hbs ファイルをサーバーから受け取ります。

これには、sling 検索パス内のすべての HBS テンプレート（/libs/ または /apps の下の .hbs ファイル）を、オーサーまたはパブリッシュから任意のユーザーが取得できる必要があります。

.hbs ファイルへの HTTP アクセスは禁止できません。

コミュニティコンポーネントの追加またはインクルード

ほとんどのコミュニティコンポーネントは、Sling アドレス可能リソースとして追加する必要があります。**​一部のコミュニティコンポーネントは、ユーザー生成コンテンツ(UGC)を書き込む場所を動的に含めたりカスタマイズしたりするために、存在しないリソースとしてテンプレートに​含める​ことができます。

どちらの場合も、コンポーネントの必要なクライアントライブラリも存在する必要があります。

コンポーネントの追加

コンポーネントの追加は、コンポーネントブラウザー（サイドキック）からページにオーサー編集モードでドラッグされたときなどに、リソース（コンポーネント）のインスタンスを追加するプロセスです。

結果は、同位ノードの下の JCR 子ノードであり、これは Sling アドレス可能です。

コンポーネントのインクルード

コンポーネントを含めると、スクリプト言語の使用など、テンプレート内の「存在しない」リソース（JCRノードなし）に参照を追加するプロセスが参照されます。

AEM 6.1以降では、コンポーネントが追加される代わりに動的に含まれる場合、コンポーネントのプロパティをオーサーデザインモードで編集できます。

一部の AEM Communities コンポーネントのみを動的にインクルードできます。次の操作を行います。

コミュニティコンポーネントガイドでは、インクルード可能なコンポーネントを追加からインクルードに切り替えることができます。

Handlebarstemplating言語を使 用する場合、存在しないリソースは、そのresourceTypeを指定す るincludeヘ ルパーを使用して含まれます。

{{include this.id path="comments" resourceType="social/commons/components/hbs/comments"}}

JSP を使用する場合、リソースはタグ cq:include を使用してインクルードされます。

<cq:include path="votes"
 resourceType="social/tally/components/voting" />
メモ

コンポーネントを、テンプレートに追加またはインクルードせずに、ページに動的に追加するには、コンポーネントのサイドローディングを参照してください。

Handlebars ヘルパー

SCF で使用できるカスタムヘルパーのリストおよび説明については、SCF Handlebars ヘルパーを参照してください。

クライアント側フレームワーク

モデル - ビュー JavaScript フレームワーク

このフレームワークには、リッチでインタラクティブなコンポーネントの開発を促進するために、Backbone.js（モデル - ビュー JavaScript フレームワーク）という拡張が含まれています。オブジェクト指向の特性は、拡張/再利用可能なフレームワークをサポートします。 クライアントとサーバー間の通信は、HTTP APIを使用することで簡略化されます。

このフレームワークは、サーバー側のHandlebarsテンプレートを利用して、クライアント用のコンポーネントをレンダリングします。 モデルは、HTTP APIによって生成されたJSON応答に基づいています。 ビューは、Handlebarsテンプレートによって生成されたHTMLにバインドされ、インタラクティビティを提供します。

CSS の規則

CSS クラスの定義と使用に推奨される規則を以下に示します。

  • 明確に名前空間化されたCSSクラスセレクター名を使用し、「heading」、「image」などの汎用名は使用しないでください。
  • CSSスタイルシートがページ上の他の要素やスタイルとうまく連携するように、特定のクラスセレクタースタイルを定義する。 例：.social-forum .topic-list .li { color: blue; }
  • スタイル設定用のCSSクラスを、JavaScriptによって駆動されるUX用のCSSクラスとは別に保持します。

クライアント側のカスタマイズ

クライアント側でのコミュニティコンポーネントの外観と動作をカスタマイズするには、以下に関する情報が含まれているクライアント側のカスタマイズを参照してください。

機能とコンポーネントの基本事項

開発者にとっての基本情報が、機能とコンポーネントの基本事項の節で説明されています。

開発者向けの追加情報については、コーディングのガイドラインの節を参照してください。

トラブルシューティング

一般的な課題および既知の問題が、トラブルシューティングの節で説明されています。

このページ