我曾经使用通配符实现列表/详细信息场景，这意味着，为了URL，我创建一个常规项来显示列表，然后在该节点下，我创建一个通配符项来表示所有可能的详细信息页面，像：
/news/*
（我通过代码生成一个友好名称来替换通配符并生成完整的URL，例如：mywebsite.com/news/the-meeting-press-release）
然后我在其他地方创建一个文件夹或一桶内容项作为我的存储库。然后我将相同的数据源分配给列表节点和通配符节点，以便为它们提供相同的内容项存储库。
我想要这样做的主要原因是使用数据源并使导航节点（生成实际页面和URL）与内容文件夹结构分开。换句话说，关注点分离：导航项目作为表示节点，内容项目作为我的数据存储库。
这是解决主/细节要求的简单方法，但我总是对此感到内疚，感觉这种技术打破了Sitecore后端的完整性（sitecore链接数据库表）和设计模式。
例如，当我查看Google Analytics时，我得到*作为项目的名称，显然感觉就像后端系统的外星人一样。
我知道这不是一个新话题。我见过像this这样的线程或像Sitecore Pipeline Processor for Virtual Items这样的想法来实现这些要求。
这有什么最好的做法吗？有什么最好的sitecore友好的方式实现这样的管道处理器的好例子？您如何通过Google Analytics上的通配符解决此问题？
答案 0 :(得分：5)
我将在这里采用与马丁不同的方式。我已经成功地使用了通配符，用于您建议的确切目的（例如，查看http://www.atpworldtour.com/news - 所有新闻文章都是带有通配符的存储卡中的项目来解析网址。）
启用页面编辑器有两个选项。
新闻文章项目成为页面。通过这种方式，您需要httpRequestBegin管道中的新处理器来解析项目的URL，然后将Sitecore.Context.Item设置为当前项目。 IIRC你可以通过设置一个管道参数属性来做到这一点。这将在页面编辑器中正常工作，因为上下文项 - 正在编辑的项 - 是新闻文章。然后页面上的其他渲染可以根据需要使用数据源。
新闻文章解析为数据源。我也尝试过这种方法。为此，您需要一个自定义数据源解析器。我在httpRequestBegin管道中使用了一个处理器，这样我就不必为每次需要数据源的渲染多次解析Url。但是在RenderRendering管道中我有一个处理器，它检测到我是否需要通配符数据源并使用已在httpRequestBegin处理器中解析的项目。
有优点＆amp;每种方法的缺点。
选项1 非常简单。这意味着您可以使用单个通配符来解析不同的＆＃34;类型＆＃34;作为演示文稿的页面项目在页面项目而不是通配符项目上，每个项目也可以有自己的自定义演示文稿，因此页面编辑器中设置的数据源对于文章是唯一的。这在某些方面也是一个缺点。使用主要文章文本等进行A / B测试变得更加困难......您仅限于测试文章版本。
选项2 在测试领域更灵活 - 您可以通过更改数据源轻松测试/个性化部分文章。但由于必须在通配符上设置演示文稿，因此您受到更多限制。因此，不部分主要文章的渲染将在所有新闻文章中具有相同的内容/设置。
答案 1 :(得分：3)
我以前和你在同一条船上。通配符项的几个问题，例如解析数据源或残疾，以在页面（体验）编辑器或嵌套通配符中运行页面。无论如何，我几次使用通配符并且他们完成了自己的工作。
我已设法根据网址（请参阅博文：Automatically resolving correct Datasources for wildcard items based on URL）正确解析数据源，但仍未对其他人进行排序。
更新：Richard建议在下面实施网页编辑器的方式，您可能会觉得这很有用
因此，我的回答是：
我建议你保持每个新闻项目都有一个页面项的经典方法，而不是使用通配符。内容作者将使用习惯方法（和页面编辑器）而不是在内容编辑器中的内容树上的某处编辑数据源。如果您使用模板和标准值正确配置 - 创建新新闻文章的麻烦最小。
如果您担心新闻文章数量可能增加 - 请使用Buckets（或建议手动策略将它们分组到文件夹中）。