6

順序付けされていないリスト（おそらくListRendererと呼ばれる）をレンダリングするプレゼンテーションコンポーネントがプロジェクトに存在するとします。ページ上の任意のListRendererにデータを提供するオプションがいくつかあります。

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

Sublayoutsをテンプレートにバインドするため、プロジェクトで＃1を使用することは通常避けていますが、これは非常に面倒です。その道を進むと、最終的には、プロジェクト内のすべての潜在的なサブレイアウトをサポートするフィールドができます。

したがって、私の解決策は、その問題を取り除くオプション＃2に向かう傾向があります。ただし、独自の質問バッグが付属しています。特定のListRendererが使用するこれらのさまざまな「リスト」はどこに配置しますか？再利用と共有を最大化するために、リストが共有されると予測した場合、通常、サイトルートの近くにこれらすべてのタイプのものを含むコンポーネントディレクトリを作成します。これは、コンテンツ作成者にとっては見つけにくく、使いにくいように思われます。コンテンツ作成者は、プレゼンテーションの詳細をクラックする方法を知らない限り、ListRendererのソースがどこにあるのか突然わかりません（これは私の平均的なユーザーにとっては少し進んでいます）。

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

この問題に取り組むための業界で認められた方法はありますか？これは常にプロジェクトで発生します。私の頭の中では、このような状況で技術的な問題とコンテンツの作成者の問題のバランスを取るのに苦労しています。

4

2 に答える 2

7

素晴らしい質問です。プロジェクトの対象者と詳細に応じて、あなたが言及したすべての手法を使用しました。問題は、Sitecore のすべてのものと同様に、それらはすべて同じ目標を達成するための有効な方法であり、あらゆる状況で機能する 1 つの答えを見つけるのに苦労することです.

私はほとんどの場合 #2 も使用しますが、コンテンツ作成者の再トレーニングが必要になる場合があり、コンテンツ作成者がターゲットとして選択できるものに制限を追加するようにしてください。私は (同じプロジェクト内で) ルートの近く (共有コンテンツ フォルダー内) と問題のアイテムの下にアイテムを構造化しました。

また、他の子ページがリスト アイテムの下に存在する場合は、リスト アイテムを別のフォルダー (共通の「リスト アイテム」アイコン) に配置し、最初のアイテムになるように並べ替えます。分離と明瞭さのために。

あらゆる種類のパーソナライゼーションと DMS を使用する場合は、とにかくデータソースを切り替える機能が必要になるため、場所をハードコーディングしないでください。

また、(まだ使用していない場合) 以下の使用を検討することもできます。

Sitecore ASP.NET CMS を使用してデータ ソース パスを ID に変換
- 後でコンテンツを再構築する必要がある場合に便利

クエリ可能なデータソースの場所
- クローンを作成する必要がある複数サイトの状況で役立ちます。または、リストがアイテムのすぐ下にあるが、柔軟に変更できる場合に標準値のデフォルトのデータソース値として設定します。

個人的には、クエリ可能なデータソースを使用することを好みます。xpath 構文の方が論理的だと思います。

于 2012-12-20T20:53:08.373 に答える
4

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

これは改善が必要なことだと思います。特に、データソースオプションを使用している場合、編集者に対する透過性が低下し、サイトのサイズが大きくなるにつれて、複雑さが増します。

私があなたに言うことができるのは、私がそれをどのように行うかということだけです。それはおそらくあなたがそれをどのように行っているかによく似ています。

1）ニュース、イベント、よくある質問などの概要ページについては、概要項目の下に項目を配置し、NewsMover共有ソースモジュールを使用して階層を自動作成します。

2）サイト間またはページ間で共有されるアイテムを含むグローバルサイトを作成します。コンポーネントのデータソースアイテムはここに配置されます。

3）標準値に存在するコンポーネントの場合、テンプレートにリストフィールドを追加します（たとえば、コンテンツページに関連アイテムを表示する場合）。

ほとんどの場合、それは論理的な選択であり、時にはそれは単に好みの問題です。

標準値に設定されているコンポーネントに対してデータソースアイテムを自動的に作成する方法についてのブログ投稿を書いたことを付け加えたいと思います。あなたがそれらを使用しているなら、それはあなたを助けるかもしれません。

編集： 「サブレイアウトをテンプレートにバインドするため、通常、プロジェクトで＃1を避けます。これは非常に面倒です。そのパスをたどると、最終的にはプロジェクト内のすべての潜在的なサブレイアウトをサポートするフィールドができます。」

今日、コンテンツエディタでフィールドとセクションを非表示にする方法についてブログを書きました。これらのフィールドを必要とするサブレイアウトがアイテムに設定されていない場合、アイテムに未使用のフィールドがたくさんあるという混乱を防ぐのに役立ちます。

于 2012-12-20T20:46:39.807 に答える