ソーシャルコンポーネントフレームワーク(SCF)によって、サーバー側とクライアント側の両方で、コミュニティコンポーネントの設定、カスタマイズおよび拡張のプロセスが簡素化されます。
フレームワークの利点
インタラクティブなコミュニティコンポーネントガイドを使用して、オーサーまたはパブリッシュインスタンスについて確認してください。
SCF では、コンポーネントは SocialComponent POJO、Handlebars JS テンプレート(コンポーネントをレンダリングするため)および CSS(コンポーネントのスタイルを設定するため)で構成されます。
Handlebars JS テンプレートでは、モデル/ビュー JS コンポーネントを拡張して、クライアントでのコンポーネントとのユーザーインタラクションを処理できます。
コンポーネントがデータの変更をサポートする必要がある場合は、従来の Web アプリケーションでのモデル/データオブジェクトと同様のデータの編集/保存をサポートするために、SocialComponent API の実装を記述できます。また、操作(コントローラー)および操作サービスを追加して、操作要求の処理、ビジネスロジックの実行、モデル/データオブジェクトでのAPIの呼び出しを行うこともできます。
クライアントが必要とするデータをビューレイヤーまたは HTTP クライアントに提供するために、SocialComponent API を拡張できます。
コンポーネントをカスタマイズまたは拡張するには、今後のリリースへのアップグレードプロセスを簡素化する /apps ディレクトリに対してオーバーレイおよび拡張のみを記述します。
このフレームワークでは、サーバー上の機能にアクセスし、クライアントとサーバー間のインタラクションをサポートするための API が提供されます。
Java API では、継承またはサブクラス化が容易な抽象クラスおよびインターフェイスが提供されます。
メインクラスについては、サーバー側のカスタマイズページで説明します。
UGCの使用方法については、ストレージリソースプロバイダーの概要を参照してください。
HTTP API によって、PhoneGap アプリ、ネイティブアプリ、その他の統合およびマッシュアップについて、カスタマイズの容易さとクライアントプラットフォームの選択がサポートされます。また、HTTP APIを使用すると、コミュニティサイトをクライアントなしでサービスとして実行でき、フレームワークコンポーネントを任意のテクノロジーで構築されたWebページに統合できます。
すべての SocialComponent に対して、フレームワークによって HTTP ベースの API エンドポイントが提供されます。エンドポイントにアクセスするには、「.social.json」セレクター+拡張子を使用してGETリクエストをリソースに送信します。 Slingを使用して、リクエストはDefaultSocialGetServlet
に渡されます。
DefaultSocialGetServlet
リソース(resourceType)をSocialComponentFactoryManager
に渡し、リソースを表すSocialComponent
を選択できるSocialComponentFactoryを受け取ります。
ファクトリを呼び出し、リソースと要求を処理できるSocialComponent
を受け取ります。
SocialComponent
を呼び出します。これは、要求を処理し、結果のJSON表現を返します。
クライアントに対するJSON応答を返します。
GET Request
デフォルトの GET Servlet が、SocialComponent がカスタマイズ可能な JSON で応答する .social.json 要求をリスニングします。
GET(読み取り)操作に加え、コンポーネントに対するその他の操作(作成、更新、削除など)を可能にするエンドポイントパターンがフレームワークによって定義されます。これらのエンドポイントは、HTTPステータスコードまたはJSON応答オブジェクトを使用して、入力を受け取り、応答するHTTP APIです。
このフレームワークエンドポイントパターンにより、CUD 操作は拡張、再利用およびテストが可能になります。
POST Request
SocialComponent 操作ごとに Sling POST :operation があります。各操作のビジネスロジックとメンテナンスコードは、HTTP API経由で、またはOSGiサービスとして他の場所からアクセスできるOperationServiceに含まれます。 フックは、アクション前/後のアクションに対するプラッガブルな操作拡張をサポートするように提供されます。
コミュニティコンテンツストアに格納された UGC の処理については、以下を参照してください。
サーバー側のコミュニティコンポーネントのビジネスロジックおよび動作のカスタマイズについて詳しくは、サーバー側のカスタマイズを参照してください。
この新しいフレームワークの顕著な変更の1つは、サーバークライアントレンダリング用の一般的なオープンソーステクノロジーであるHandlebars JSテンプレート言語(HBS)の使用です。
HBS スクリプトは、単純で、ロジックがなく、サーバーとクライアントの両方でコンパイルされ、オーバーレイやカスタマイズが容易であり、HBS ではクライアント側のレンダリングがサポートされているのでクライアント UX と自然にバインドします。
このフレームワークでは、SocialComponent の開発に便利な複数の Handlebars ヘルパーが提供されます。
サーバーで、Sling は GET 要求を解決するときに、要求への応答に使用されるスクリプトを識別します。スクリプトがHBSテンプレート(.hbs)の場合、Slingは要求をHandlebarsエンジンに委任します。 次に、Handlebarsエンジンは、適切なSocialComponentFactoryからSocialComponentを取得し、コンテキストを構築して、HTMLをレンダリングします。
Handlebars(HBS)テンプレートファイル(.hbs)は、.jsp および .html テンプレートファイルに似ていますが、クライアントブラウザーとサーバーの両方でレンダリングに使用できる点が異なります。そのため、クライアント側テンプレートを要求するクライアントブラウザーは、.hbs ファイルをサーバーから受け取ります。
これには、sling 検索パス内のすべての HBS テンプレート(/libs/ または /apps の下の .hbs ファイル)を、オーサーまたはパブリッシュから任意のユーザーが取得できる必要があります。
.hbs ファイルへの HTTP アクセスは禁止できません。
ほとんどのコミュニティコンポーネントは、Sling アドレス可能リソースとして追加する必要があります。**一部のCommunitiesコンポーネントは、ユーザー生成コンテンツ(UGC)を書き込む場所を動的に含めたりカスタマイズしたりするために、既存でないリソースとしてテンプレートに含めることができます。
どちらの場合も、コンポーネントの必要なクライアントライブラリも存在する必要があります。
コンポーネントの追加
コンポーネントの追加は、コンポーネントブラウザー(サイドキック)からページにオーサー編集モードでドラッグされたときなどに、リソース(コンポーネント)のインスタンスを追加するプロセスです。
結果は、同位ノードの下の JCR 子ノードであり、これは Sling アドレス可能です。
コンポーネントのインクルード
コンポーネントを含めると、スクリプト言語の使用など、テンプレート内の"存在しない"リソース(JCRノードなし)に参照を追加するプロセスを指します。
AEM 6.1以降では、コンポーネントが追加される代わりに動的に含まれる場合、コンポーネントのプロパティをauthor *design *modeで編集できます。
一部の AEM Communities コンポーネントのみを動的にインクルードできます。次の項目があります。
コミュニティコンポーネントガイドでは、インクルード可能なコンポーネントを追加から含めるに切り替えることができます。
Handlebarstemplaking言語を使用する場合、既存でないリソースは、そのresourceTypeを指定してinclude helperbyを使用して含められます。
{{include this.id path="comments" resourceType="social/commons/components/hbs/comments"}}
JSP を使用する場合、リソースはタグ cq:include を使用してインクルードされます。
<cq:include path="votes"
resourceType="social/tally/components/voting" />
コンポーネントを、テンプレートに追加またはインクルードせずに、ページに動的に追加するには、コンポーネントのサイドローディングを参照してください。
SCF で使用できるカスタムヘルパーのリストおよび説明については、SCF Handlebars ヘルパーを参照してください。
このフレームワークには、リッチでインタラクティブなコンポーネントの開発を促進するために、Backbone.js(モデル - ビュー JavaScript フレームワーク)という拡張が含まれています。オブジェクト指向の特性は、拡張可能/再利用可能なフレームワークをサポートします。 HTTP APIを使用すると、クライアントとサーバー間の通信が簡単になります。
フレームワークは、サーバー側のハンドルテンプレートを利用して、クライアント用のコンポーネントをレンダリングします。 モデルは、HTTP APIによって生成されたJSON応答に基づいています。 表示は、Handlebarsテンプレートによって生成されるHTMLに連結され、インタラクティブ機能を提供します。
CSS クラスの定義と使用に推奨される規則を以下に示します。
.social-forum .topic-list .li { color: blue; }
クライアント側でのコミュニティコンポーネントの外観と動作をカスタマイズするには、以下に関する情報が含まれているクライアント側のカスタマイズを参照してください。
開発者にとっての基本情報が、機能とコンポーネントの基本事項の節で説明されています。
開発者向けの追加情報については、コーディングのガイドラインの節を参照してください。
一般的な課題および既知の問題が、トラブルシューティングの節で説明されています。