Sitecore内容树架构

ray*_*min 6 sitecore hierarchy sitecore6

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

  1. 在内容项上有一个TreeList(或TreeListEx)字段,并从中读取ListRenderer.
  2. 通过演示详细信息向ListRenderer提供DataSource(或其他参数).

我通常在我的项目中避免使用#1,因为它将Sublayouts绑定到模板,这会非常混乱.如果沿着这条路走下去,最终你将拥有支持项目中每个潜在子布局的字段.

所以我的解决方案倾向于选项#2,它摆脱了这个问题.然而,它确实带有一系列问题.我在哪里为给定的ListRenderer使用这些不同的"列表"?为了最大化重用和共享,我通常在站点根目录附近创建一个包含所有这些类型的组件的组件目录,如果我预测将共享列表.对于内容作者来说,这似乎更难找到并且更难以使用,他们突然不知道他们的ListRenderer的来源在哪里,除非他们知道如何破解演示细节(这对我的普通用户来说略微提前).

如果我觉得列表不会被共享,并且非常特定于页面,我会将它们直接放在相关项目的下方.然而,这倾向于混淆内容树,并且任何动态生成的导航子布局然后必须在其生成到其的链接之前检查项目是否是实际页面.我在Sitecore中工作的越多,我使用这种方法的次数就越少,但对内容作者来说似乎更容易.使用此方法时,可以更轻松地访问信息.

是否有任何行业认可的方法来解决这个问题?它始终在项目中发生,在我的脑海中,我努力在这些情况下平衡技术和内容作者关注问题.

jam*_*kam 7

好问题.我已经使用了你提到的所有技术,具体取决于项目的受众和细节.问题在于,就像Sitecore一样,它们都是实现相同目标的有效方法,您将很难找到一个适用于所有情况的答案.

我几乎总是使用#2,但是一些内容作者可能需要重新训练,并确保对内容作者能够选择作为目标的内容添加限制.我(在同一个项目中)构建了根目录(在共享内容文件夹中)和相关项目下的项目,具体取决于我认为可以提供最佳上下文的内容.

此外,如果项目下方和列表项目下面还存在其他子页面,那么我会将列表项目放在一个单独的文件夹中(使用常见的"列表项"图标")并将其重新排序为第一项分离和清晰.

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

您也可以(如果您还没有)想要考虑使用:

使用Sitecore ASP.NET CMS将数据源路径转换为ID
- 如果您需要在以后重新构建内容,则非常有用

可查询的数据源位置
- 当您需要进行克隆时,可用于多站点情况,或者当列表直接位于项目下方时设置为标准值中的默认数据源值,但您可以灵活地进行更改.

我更喜欢亲自使用可交换的数据源,我发现xpath语法更合乎逻辑.


Ruu*_*ier 4

正如马克所评论的,没有真正的行业标准。

我觉得这是一个需要改进的地方。特别是当您使用数据源选项时,事情对编辑者来说变得不那么透明,并且随着网站规模的增长,复杂性也随之增加。

我只能告诉你我会如何做,这很可能很像你正在做的事情。

1) 对于新闻、事件和常见问题等概述页面,我会将这些项目放在概述项目下方,并使用 NewsMover 共享源模块自动创建层次结构。

2) 我将创建一个全局站点,其中包含跨站点或页面共享的项目。组件的数据源项将放置在此处。

3)对于标准值上存在的组件,我将在模板中添加一个列表字段(例如,当您在内容页面上显示相关项目时)

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

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

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

今天,我在博客中介绍了一种在内容编辑器中隐藏字段和部分的方法(如果需要这些字段的项目上没有设置子布局),这有助于防止项目上有大量未使用的字段而造成混乱。