【问题标题】：Avoid hard-coded TCM URI in Tridion-Related Code避免在 Tridion 相关代码中硬编码 TCM URI
【发布时间】：2013-01-10 14:27:52
【问题描述】：

我们经常需要 Tridion 相关代码中的特定项目（模式、模板或组件）。模板、内容交付、工作流或业务连接器（核心服务）经常需要引用 Tridion Content Manager URIs。我们可以链接到组件，但我通常会看到硬编码的值或其他所有内容的 WebDAV URL。

硬编码值

我了解硬编码 Tridion Content Manager (Native) URI 是一种不好的做法，除了少数情况：

我们尽可能使用给定的 API 或 WebDAV URL 来引用项目，否则我们必须避免在任何引用 TCM URI 的东西上使用 Content Porter（或者以某种方式使这些引用在 Tridion 之外“可配置”）。

WebDAV 网址

WebDAV URLs 似乎更好有几个原因：

设计模板构建块 (TBB) 或其他模板格式中的硬编码值在 SDL Content Porter 中保持不变（在 CMS 环境中移动时会破坏关系，下面描述的例外情况）
引用特定项目的“配置”组件在使用 SDL Content Porter 时也做得更好，尽管不同名称的路径可能会“破坏”关系

除了具有与 Content Porter 配合良好的模板外，我还想本地化较低出版物中的文件夹和/或结构组。这可以帮助：

至少对于模板构建块而言，为了使引用“对内容移植器友好”，我知道我们可以在组件中使用 WebDAV 网址，确保将每个路径本地化到子出版物中的正确位置。例如：

只要我们设置发布元数据并将字段本地化到每个发布的正确路径，这将适用于大多数情况。

我相信我们可以选择使用 includes 或 map unmanaged URI in template code。

有人有 #include 方法的示例吗？我是否在 TBB 和/或 DWT 的顶部使用它，并且不管模板中介器如何，引用都会被替换（例如这与 XSLT Mediator、Razor Mediator 等一起工作？）
包含的参考是否适用于较低的出版物，还是仅适用于 Content Porter？ 换句话说，如果我引用“tcm:5-123”，模板是否会正确引用“tcm :17-123" 在出版物 17 中？

【问题讨论】：

标签： tridion

【解决方案1】：

我倾向于遵循一些简单的规则...

没有任何正当理由可以在任何东西（模板代码、配置组件、配置文件）中使用 TCM ID。
如果我需要配置 webdav URL，我会尽量使它们始终为“相对”，通常从“/Building%20Blocks”而不是发布名称开始。在运行时，我可以使用 Publication.WebDavUrl 或 PublicationData.LocationInfo.WebDavUrl 来获取 URL 的其余部分
Tridion 知道如何处理托管链接，因此尽可能使用它们。（托管链接是您在 Tridion XML 中看到的 xlink:href 内容）。

我还倾向于使用“配置页面”进行内容交付，其中的模板输出我可能需要从内容交付应用程序“了解”的 TCM ID。然后在运行时将其作为一组配置变量或作为字典或作为一组常量加载（我想这取决于我那天的感受）。

【讨论】：

【解决方案2】：

虽然我们通常将模板类型实现称为模板中介，但这并不是故事的全部。模板类型实现由模板中介者和Template Content Handler 组成，尽管后者是可选的。给定的实现是否会正确处理“包含”不取决于中介，而是处理程序。

搜索AbstractTemplateContentHandler可以找到文档中的一个很好的起点。

SDL Tridion 自己的 Dreamweaver 模板实现具有这样的处理程序。我刚刚查看了Razor implementation，它目前使用了 Dreamweaver 内容处理程序。显然，YMMV 用于现有的各种 XSLT 模板类型实现。

由于这是 SDL Tridion 的一个可扩展点，包含的引用是否会在较低的出版物中“正确”工作取决于实施者对这意味着什么的看法。

一种有趣的可能性是实现您自己的行为如您所愿的自定义处理程序。模板类型配置（在 Tridion Content Manager 配置文件中）允许独立指定给定模板类型的中介和内容处理程序，这意味着您可以为现有模板类型自定义内容处理行为。

【讨论】：