Sitecore的內容樹架構

Question

假設存在着呈現一個無序列表項目中的表象的成分，我們有一個頁面上的任何給定ListRenderer提供數據的幾個選項（稱爲ListRenderer，也許吧。）：

1. 在內容項上有一個TreeList（或TreeListEx）字段，並從中讀取ListRenderer。
2. 通過演示詳細信息向ListRenderer提供一個DataSource（或其他參數）。

我通常在我的項目中避免＃1，因爲它將Sublayouts綁定到模板，這會變得非常混亂。如果你沿着這條路走下去，最終你會有一些領域來支持你項目中的每一個可能的子佈局。

所以我的解決方案傾向於選項＃2，它擺脫了這個問題。但是，它的確有一些問題。我在哪裏爲給定的ListRenderer使用這些不同的「列表」？爲了最大限度地重用和共享，我通常在站點根目錄附近創建一個包含所有這些類型的組件目錄，如果我預測這些列表將被共享。對於內容作者而言，這似乎不太容易找到和難以使用，他們突然不知道他們的ListRenderer的源代碼是什麼，除非他們知道如何破解演示文稿細節（這對我的普通用戶而言稍微先進）。

如果我覺得列表不會被共享，並且對頁面非常具體，我會將它們直接放在相關項目的下面。但是，這有一種混淆內容樹的趨勢，並且任何動態生成的導航子佈局都必須檢查項目是否爲實際頁面，然後纔會生成指向該頁面的鏈接。我在Sitecore工作得越多，使用這種方法的次數就越少，但內容作者似乎更容易。當你使用這種方法時，訪問信息要容易得多。

有沒有行業接受的方式來解決這個問題？它始終在項目中發生，在我的頭腦中，我努力在這些情況下平衡技術和內容作者關注的問題。

Answer 1

正如Mark所評論的，沒有真正的行業標準。

我覺得這是需要改進的地方。 特別是當您使用DataSource選項時，對編輯來說事情變得不那麼透明，並且隨着網站規模的增長，複雜性也隨之增加。

我可以告訴你的是我會怎麼做，這很可能就像你如何做。

1）對於新聞，事件和常見問題解答項目等概覽頁面，我會將項目置於概覽項目下，並使用NewsMover共享源模塊自動創建層次結構。

2）我將創建一個全球站點，其中包含跨站點或頁面共享的項目。組件的DataSource項目將放在這裏。

3）對於存在於標準值的部件，我將在列表字段添加到模板中（例如，當顯示內容網頁上的相關項目）

大多數情況下這是一個合乎邏輯的選擇和有時候這只是一個品味問題。

我想補充一點，我已經寫了一個blog post關於如何爲標準值設置的組件自動創建數據源項目。如果你使用這些，這可能會有所幫助。

編輯： 「我通常會避免＃1在我的項目，因爲它結合Sublayouts到模板，它得到相當混亂，如果你走這條道路，最終你將不得不字段以支持每一個潛在的sublayout你。項目。」

今天我有blogged關於在內容編輯器中隱藏字段和部分的方法，如果在需要這些字段的項目上沒有設置子佈局設置，這有助於防止您的大量未使用字段混亂項目。

Answer 2

偉大的問題。我已經使用了您提到的所有技術，具體取決於項目的受衆和具體情況。問題是，與Sitecore的所有事情一樣，它們都是實現相同目標的有效方式，您將很難找到適用於所有情況的答案。

我幾乎總是使用＃2，但也許有必要對內容作者進行再培訓，並確保您添加內容作者可以選擇作爲目標的限制。我（在同一個項目中）根據我認爲會提供最佳上下文的內容，在根目錄（在共享內容文件夾中）和相關項目下構建項目。另外，如果其他子頁面將存在於項目下方以及列表項目中，那麼我會將列表項目放入單獨的文件夾（帶有一個共同的「列表項目」圖標），並重新排列它對於分離和清晰度中的第一項。

如果你想使用任何類型的個性化和DMS，那麼你就需要轉出的數據源的能力，無論如何，所以你不應該硬編碼位置。

你也可能（如果您還沒有）想要考慮使用：

Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- 有用的，如果你需要在以後調整你的內容

Queryable Datasource Locations
- 可爲多點的情況下，當你需要進行克隆，或者設置爲當名單是標準值的缺省數據源值直接在物品下方，但可以讓您靈活地改變它。

我更喜歡個人使用可調數據源，我發現xpath語法更符合邏輯。