Sitecore内容树体系结构

假设在一个项目中存在一个呈现无序列表的表示组件（可能称为ListRenderer）。我们有两个选项可以向页面上的任何给定ListRenderer提供数据：

在内容项上有一个TreeList（或TreeListEx）字段，并从中读取ListRenderer

通过演示文稿详细信息向ListRenderer提供数据源（或其他参数） 我通常在项目中避免使用#1，因为它将子布局绑定到模板，这会变得非常混乱。如果您沿着这条路走下去，最终您将拥有支持项目中每个潜在子布局的字段

因此，我的解决方案倾向于选项2，它解决了这个问题。然而，它也有自己的问题包。对于给定的ListRenderer，我应该将这些不同的“列表”放在哪里？为了最大限度地重用和共享，我通常在站点根目录附近创建一个components目录，其中包含所有这些类型的内容，如果我预测列表将被共享的话。对于内容作者来说，这似乎不太容易找到，也更难使用，他们突然不知道ListRenderer的源代码在哪里，除非他们知道如何打开演示细节（这对于我的普通用户来说稍微高级一点）

如果我觉得列表不会被共享，并且非常特定于页面，我会将它们直接放在相关项目的下面。不过，这有可能会弄乱内容树，任何动态生成的导航子布局都必须在生成指向该项目的链接之前检查该项目是否为实际页面。我在Sitecore中工作的越多，使用这种方法的人就越少，但对内容作者来说似乎更容易。当您使用这种方法时，可以更轻松地访问信息

---

有没有行业公认的方法来解决这个问题？它总是发生在项目中，在我的头脑中，我很难在这样的情况下平衡技术和内容作者的关注。

正如Mark所评论的，没有真正的行业标准

我觉得这是需要改进的。 特别是当您使用DataSource选项时，事情对编辑器的透明性会降低，而且随着站点的大小增加，复杂性也会增加

我能告诉你的就是我会怎么做，这很可能和你现在做的很像

1） 对于新闻、事件和faq项目等概述页面，我将把这些项目放在概述项目下面，并使用NewsMover共享源模块自动创建层次结构

2） 我将创建一个全局站点，其中包含跨站点或页面共享的项目。组件的数据源项将放在这里

3） 对于标准值上存在的组件，我将向模板添加一个列表字段（例如，当您在内容页上显示相关项时）

大多数情况下，这是一个合乎逻辑的选择，有时只是品味的问题

我想补充一点，我已经写了一篇关于如何为基于标准值设置的组件自动创建数据源项的文章。如果您正在使用这些，这可能会对您有所帮助

编辑： “我通常在项目中避免使用#1，因为它会将子布局绑定到模板，这会变得非常混乱。如果沿着这条路走下去，最终会有字段来支持项目中的每个潜在子布局。”

---

今天，我介绍了一种在内容编辑器中隐藏字段和节的方法，如果项目上没有设置需要这些字段的子布局，这有助于避免项目上有大量未使用字段的混乱情况。

好问题。我已经使用了你提到的所有技术，这取决于观众和项目的具体情况。问题是，与Sitecore的所有内容一样，它们都是实现相同目标的有效方法，您将很难找到一个在任何情况下都适用的答案

我几乎总是使用#2，但一些内容作者再培训可能是必要的，并确保您为内容作者能够选择的目标添加限制。我已经（在同一个项目中）在根目录附近（在共享内容文件夹中）和相关项下组织了这些项，这取决于我认为可以提供最佳上下文的内容

此外，如果该项目和列表项目下还存在其他子页面，那么我会将列表项目放在一个单独的文件夹中（带有一个常见的“列表项目”图标），并将其重新排序为第一个项目，以便于分离和清晰

如果您想使用任何类型的个性化和DMS，那么您将需要能够切换出数据源，因此您不应该硬编码位置

你也可以（如果你还没有）想考虑使用：

如果您以后需要重新构建内容，此功能非常有用

对于需要进行克隆的多站点情况非常有用，或者当列表直接位于项目下方时，可以将其设置为标准值中的默认数据源值，但可以灵活地进行更改

---

我更喜欢亲自使用可伸缩的数据源，我发现XPath语法更合乎逻辑。

简单的答案是“否”，没有行业标准。你提到的所有东西都是常见的东西，即使是经验丰富的SITECORE开发人员也经常考虑。这很大程度上是基于需求的，例如，如果你支持这些模块化子页面的页面编辑器，那么你是WAW。nt方法#2，具有全局共享的数据源文件夹。如果他们使用内容编辑器并且不喜欢演示细节，有时子项会使其更容易。您需要选择一种方法并在每个项目上强制使用它，或者根据对编辑器的要求定义每个项目的方法（我的首选）你会得到关于这个问题的创造性解决方案的检查和建议。我很想听听其他人对此的看法——这似乎是一个相当可靠的想法。