主/细节困境:通配符项与虚拟项目的Sitecore管道或任何更好的主意？

Question

我曾经使用通配符实现列表/详细信息场景,这意味着,为了URL,我创建一个常规项来显示列表,然后在该节点下,我创建一个通配符项来表示所有可能的详细信息页面,如:

/news/*  

(我通过代码生成一个友好的名称来替换通配符并生成完整的URL,例如:mywebsite.com/news/the-meeting-press-release)

然后我在其他地方创建一个文件夹或一桶内容项作为我的存储库.然后我将相同的数据源分配给列表节点和通配符节点,以便为它们提供相同的内容项存储库.

我想要这样做的主要原因是使用数据源并使导航节点(生成实际页面和URL)与内容文件夹结构分开.换句话说,关注点分离:导航项目作为表示节点,内容项目作为我的数据存储库.

这是解决主/细节要求的简单方法,但我总是对此感到内疚,感觉这种技术打破了Sitecore后端的完整性(sitecore链接数据库表)和设计模式.

例如,当我查看分析时,我得到*作为项目的名称,显然它感觉像后端系统的外星人.

我知道这不是一个新话题.我已经看到像这样的线程或像Sitecore Pipeline Processor for Virtual Items这样的想法来实现这样的要求.

这有什么最好的做法吗？有什么最好的sitecore友好的方式实现这样的管道处理器的好例子？您如何使用Google Analytics上的通配符来解决此问题？

Answer 1

我将在这里采用与马丁不同的方式.我已经多次成功使用Wildcards用于您建议的确切目的(例如,请查看http://www.atpworldtour.com/news - 所有新闻文章都是带有通配符的存储卡中的项目来解析网址) .

启用页面编辑器有2个选项.

1. 新闻文章项目成为页面.通过这种方式,您需要在httpRequestBegin管道中使用新的处理器来解析项目的URL,然后设置Sitecore.Context.Item为当前项目.IIRC你可以通过设置一个管道参数属性来做到这一点.这将在页面编辑器中正常工作,因为上下文项 - 正在编辑的项 - 是新闻文章.然后页面上的其他渲染可以根据需要使用数据源.

2. 新闻文章解析为Datasource.我也尝试过这种方法.为此,您需要一个自定义数据源解析器.我在httpRequestBegin管道中使用了一个处理器,这样我就不需要为每个需要数据源的渲染多次解析Url.但是在RenderRendering管道中我有一个处理器,检测到我是否需要通配符数据源并使用已在httpRequestBegin处理器中解析的项目.

每种方法都有利弊.

选项1很简单.这意味着您可以使用单个通配符来解析页面项的不同"类型",因为演示文稿位于页面项而不是通配符项上,每个项目也可以有自己的自定义演示文稿,因此在页面编辑器中设置的数据源将会是文章的独特之处.这在某些方面也是一个缺点.使用主要文章文本等进行A/B测试变得更加困难......您仅限于测试文章版本.

选项2在测试领域更灵活 - 您可以通过更改数据源轻松测试/个性化部分文章.但由于必须在通配符上设置演示文稿,因此您受到更多限制.因此,不属于主要文章的渲染将在所有新闻文章中具有相同的内容/设置.