Sitecoreを初めて使用する開発者向けのコンテンツオーサリングの概念

Version: 22.x
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

このトピックでは、コンテンツオーサリングに関連するSitecore固有の用語と概念について簡単に紹介します。

コンテンツ作成者

コンテンツを管理するSitecoreユーザーは、コンテンツ作成者と呼ばれます。Sitecoreは、これらのユーザーがページの作成、ページへのコンポーネントの追加、コンポーネントによって表示されるコンテンツの編集、およびパーソナライゼーション ルールの定義を行うことができるコンテンツ作成インターフェイスを提供します。

次のトピックを確認して、コンテンツ作成者が開発者が構築するコンポーネントとどのように連携するか、およびページ内のコンポーネントの位置を制御する方法を理解できます。

テンプレート

コンテンツ作成者がコンテンツ管理を簡単に行えるように、Sitecoreの開発者はテンプレート アイテムを作成してソリューション固有の情報アーキテクチャを設定します。Sitecoreのテンプレートの概念は、オブジェクト指向プログラミングのクラスと似ています。テンプレートは、クラスと同様に、特定のタイプのオブジェクトに適用可能なフィールドのセットを定義します。

テンプレートは、コンテンツ作成者がSitecoreで管理するすべての構成要素です。これらは、以下を定義するために使用されます。

  • ページの種類 (ホーム ページ、ランディング ページ、製品ページなど)。

  • 画像、動画、カルーセルなどのコンポーネントデータ。

  • 任意のアイテム (リスト アイテム、共有コンテンツ フォルダーなど)。

開発者は、Sitecoreコンテンツ ツリーのTemplatesノードでテンプレートを定義します。

コンテンツ作成者は、通常、これらのアイテムを表示しません。これは、コンテンツ作成者の作業がツリーのコンテンツ部分に限定されるためです。既存のテンプレートに基づいてコンテンツ項目を作成します。プログラミングの例えに戻ると、これはクラスのインスタンスを作成するようなものです。

レイアウト

ページ テンプレートを他のすべての種類のテンプレートと区別する要因は、レイアウト データの存在です。

レイアウト データは、ページのレンダリング方法をSitecoreに通知します。レンダリングとプレースホルダーで構成されます。

先端

Sitecore開発者は、レイアウト データを編集するためにSitecoreインターフェイスにアクセスする方法 (LayoutセクションのPresentationタブでDetailsをクリックすることで、レイアウト データをpresentation detailsまたはlayout detailsと呼ぶことがあります。

レンダリング

レンダリングは、ページUIの目立たない要素です。ボタンのように単純なものから、Site Search Results。コンテンツ作成者は、レンダリングをページに追加し、コンテンツを設定することでページを構築します。

レンダリングSDKを使用してフロントエンド アプリケーションをビルドする場合、レンダリング アイテムは、特定のレンダリングのHTMLを生成するために使用するフロントエンド コンポーネントと、コンポーネントのデータ ソースとして機能するコンテンツ アイテムを作成するときに使用するテンプレートをSitecoreに通知します。

プレースホルダー

プレースホルダーは、コンテンツ作成者がレンダリングを挿入できるページ上の場所です。

Sitecore開発者は、ページ レベルでプレースホルダーのルールを設定し、コンポーネント内にプレースホルダーをネストすることもできます。プレースホルダーが異なれば、レンダリングも異なります。たとえば、ヘッダープレースホルダーでは、ナビゲーション、ロゴ、および言語セレクターコンポーネントを許可できます。タイプに関係なく、すべてのページにはヘッダーが必要であるため、このプレースホルダーはすべてのページに表示されます。ただし、製品関連のコンポーネントのみを許可するプレースホルダーは、製品ページにのみ存在します。

すべてをまとめる

ページの種類、プレースホルダー、レンダリングを分割するための普遍的な公式はありません。Sitecoreの開発者は、ビジネス関係者と協力して、各コンテンツチームに最適なアプローチを特定する必要があります。

ページの種類が少なく、プレースホルダのネストが浅いと、より多くのコンポーネントがより多くの場所で使用できるようになります。また、コンポーネントを適切にグループ化するかどうかは、コンテンツ作成者の責任です。このアプローチは、ビジネスが作成者に編集オプションの柔軟性を持たせたい場合、たとえば、コンテンツ チームの各メンバーがアプリのすべての部分の管理を支援する場合に推奨されます。

逆に、ページの種類が増え、プレースホルダーのネストが深いと、規範的な編集ワークフローが発生する可能性があります。このアプローチは、ビジネスでオーサリングの制限を適用する場合に適しています。たとえば、コンテンツ チーム メンバーに特定のロールがある場合、異なるロールがさまざまなアプリ パーツを担当します。

何かフィードバックはありますか?

この記事を改善するための提案がある場合は、