Sitecore動的プレースホルダーとJSS
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
動的プレースホルダー はSitecore 9.0で導入されました。JSSは、この機能を利用して、JSSアプリケーションでレイアウトとコンテンツを動的に駆動します。
Sitecoreアーキテクチャの中心となるのは、プレースホルダー キーを使用してコンポーネントの場所に対応するデータ駆動型のページ レイアウトです。
コンポーネントは、コード/マークアップで使用可能なプレースホルダーを定義し、ページ上の定義されたプレースホルダーに従って配置されます。プレースホルダーアドレスは通常、完全修飾パスであり、URLパスのようにスラッシュ('/')で区切られたプレースホルダーの階層全体が含まれます。
次のアニメーションは、Sitecoreレイアウト エンジンがページ レイアウトを構成する方法を示しています。
このシステムの欠点は、同じコンポーネントを同じプレースホルダーアドレスに複数回配置しようとすると明らかになります。
次のレイアウト例では、プレースホルダパス /phContent/phTabが与えられたときに、タブをどのタブコンポーネントに配置するべきかが不明です。すぐに使用できるSitecoreは、最初のTabsコンテナーにTabコンポーネントを配置します。
この問題を解決するには、プレースホルダー キーを動的にする必要があります。考えられるアプローチには、次のようなものがあります。
-
コンポーネントの位置に基づいてプレースホルダーキーにインデックスをアタッチします。たとえば、/phContent/phTab_1.
-
Sitecoreがページに配置されるときにコンポーネントに付与される一意の識別子 (UID) を利用します。たとえば、/phContent/phTab_8DFE46A3-5D17-43E1-835D-129D18BD59AC.
-
前のアプローチの一部の組み合わせ。
UIDアプローチは、エクスペリエンスエディターでコンポーネントを移動するなどのシナリオに最も耐障害性があります。
Sitecore JSSの動的プレースホルダー
Sitecoreの動的プレースホルダーをJSSと一緒に使用すると、次のような課題があります。
-
アプリケーションはSitecoreなしでレンダリングできる必要があり、アプリケーションとそのコンポーネントをSitecoreにインポートする前にUIDのレンダリングにアクセスできないようにします。
-
開発者はJavaScriptオブジェクトを使用してコンポーネント レイアウトを構造化しており、特定のレイアウトがSitecoreレイアウト エンジンの欠点によって影響を受けるかどうかを検討したくありません。
-
同様に、コンポーネントにプレースホルダを追加する場合、開発者はプレースホルダが動的である必要があるかどうかを検討したくありません。
これらの課題を克服するために、Sitecore JSSは次の設計上の決定を行いました。
-
ページ上のコンポーネントをアドレス指定する代わりに、ツリー/ネストされたルートレイアウト構造を利用します。JSSによって消費されるルート・データは、プレースホルダー・コレクション自体の中に子コンポーネントを配置する必要があるため、レイアウト内のどこにコンポーネントを配置するかについてあいまいさはありません。
-
コンポーネントをインポートしてデータをSitecoreにルーティングするときは、ルート プレースホルダーの直接の子を除くすべてのプレースホルダーが動的であると仮定します。
-
レンダリングUIDを含む動的プレースホルダ形式を利用します。
-
Sitecoreのインポート前にマニフェストを作成するときに、レンダリングUIDを生成します。この戦略により、最終的には、必要に応じて動的プレースホルダー形式の柔軟性が向上します。