サイトコアのコンテンツツリーアーキテクチャ

Question

のは、順不同リストをレンダリングし、プロジェクトのプレゼンテーションコンポーネントが存在するとしましょう私たちは、ページ上の任意のListRendererにデータを供給するカップルのオプションがあります（おそらく、ListRendererと呼ばれるが。）：

1. コンテンツアイテムにTreeList（またはTreeListEx）フィールドがあり、そこからListRendererを読み取るようにします。
2. プレゼンテーションの詳細を介して、ListRendererにDataSource（または他のパラメータ）を供給します。

私は通常サブレイアウトをテンプレートにバインドするので、私のプロジェクトでは＃1を避けていますが、これはかなり面倒です。そのパスを下ると、最終的にプロジェクト内のすべての潜在的なサブレイアウトをサポートするフィールドが表示されます。

私のソリューションは、その問題を取り除くオプション＃2に向く傾向があります。しかし、それは自分の質問のバッグが付属しています。与えられたListRendererがこれらのさまざまな "List"をどこに入れて使うのですか？再利用と共有を最大限にするために、私はリストが共有されると予測すれば、通常、サイトルートの近くにこれらのタイプのものをすべて含むコンポーネントディレクトリを作成します。これは、プレゼンテーションの詳細を開く方法を知っていないかぎり（私の平均的なユーザーにとっては少し進んでいる）、ListRendererのソースがどこにないのか突然わからないコンテンツ作成者にとって、使いにくく、使いにくいようです。

リストが共有されず、ページに固有のものだと思われる場合は、問題のアイテムのすぐ下に配置します。しかし、コンテンツツリーを混乱させる傾向があり、動的に生成されたナビゲーションサブレイアウトは、項目がリンクを生成する前に実際のページであるかどうかをチェックする必要があります。私がSitecoreで働くほど、このアプローチは少なくなりますが、コンテンツ作成者にとってはより簡単に思えます。このアプローチを使用すると情報へのアクセスがずっと簡単になります。

業界で認められているこの問題に近づく方法はありますか？それはいつもプロジェクトで起こり、私の頭の中では、私はこれらのような状況で技術とコンテンツの著者の懸念をバランスさせるために奮闘しています。

Answer 1

Markがコメントしたように、実際の業界標準はありません。

改善が必要なような気がします。 特にDataSourceオプションを使用している場合は、エディタにとっては透過的ではなくなり、サイトのサイズが大きくなるほど複雑になります。

私があなたに言うことができるのは、私がそれをやる方法です。これはあなたがどのようにしているかと非常によく似ています。

1）ニュース、イベント、およびfaqアイテムなどの概要ページについては、概要アイテムの下にアイテムを配置し、NewsMover共有ソースモジュールを使用して階層を自動作成します。

2）サイトやページで共有されるアイテムを含むグローバルサイトを作成します。コンポーネントのDataSourceアイテムがここに配置されます。標準値上に存在するコンポーネントについては

3）あなたがコンテンツページに関連する項目を表示したときに、私は、例えば（テンプレートにリストフィールドを追加しますが）

ほとんどの場合、それは論理的な選択だと時にはそれは味の問題です。

標準値に設定されているコンポーネントのデータソース項目を自動的に作成する方法については、blog postと書いておきます。あなたがそれらを使用しているなら、それはあなたを助けるかもしれません。

編集：それはかなり厄介取得され、テンプレートにサブレイアウトを結合するので 「私は通常私のプロジェクトで1位を避けるあなたは、そのパスの下に行く場合は、最終的に、あなたの内のすべての潜在的sublayoutをサポートするためのフィールドがあります。プロジェクト。"

今日、私はに、フィールドエディタでフィールドとセクションを隠す方法について説明しました。これらのフィールドが必要な項目にサブレイアウトが設定されていないと、未使用のフィールドがたくさんあることの混乱を防ぎますアイテム。

Answer 2

偉大な質問です。私はあなたが言及したすべてのテクニックを使用しました、観客とプロジェクトの詳細に応じて。問題は、Sitecoreのすべてのものと同様に、すべて同じ目的を達成するための有効な方法であり、あらゆる状況でうまくいく1つの答えを見つけるのに苦労するということです。

は、私はほとんどいつものようにも＃2を使用しますが、一部のコンテンツ作成者は多分、必要な再訓練し、コンテンツ作成者がターゲットとして選択することができるものに制限を追加してください。私は（同じプロジェクト内で）ルートの近くのアイテム（共有コンテンツフォルダ内）とそのアイテムの下に、最良のコンテキストを提供すると感じたものに応じて構造化しました。

また、他の子ページがアイテムとリストアイテムの下に存在する場合は、リストアイテムを別のフォルダ（共通の「リストアイテム」アイコン）に置き、分離と明確にするため最初の項目で。

あなたは、パーソナライゼーションおよびDMSの任意の種類を使用したい場合、あなたはあなたがハードコードの場所いけないので、とにかくデータソースを切り替える機能が必要になります。

あなたは（あなたがまだの場合）も使用して検討する必要があります：

Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- 後日、あなたのコンテンツを再構築する必要がある場合に便利

Queryable Datasource Locations
- あなたがリストである標準値のデフォルトのデータソースの値として、クローン、または設定を行う必要がある場合、マルチサイトの状況に便利ですアイテムのすぐ下にありますが、それを変更する柔軟性があります。

私はクエリー可能なデータソースを個人的に使うことを好みますが、xpath構文はより論理的です。