避免Tridion相关代码中硬编码的TCM URI

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

硬编码值 我知道硬编码Tridion内容管理器（本机）URI是一种糟糕的做法，除了以下几种情况：

• 简化示例代码并明确变量是什么
• 当生成用于内容交付（CD）API逻辑时

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

WebDAV URL 由于以下几个原因，情况似乎有所好转：

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

用例 除了使用与Content Porter配合良好的模板外，我还希望在较低的出版物中本地化文件夹和/或结构组。这有助于：

• 阅读不同语言的CMS作者
• 将项目名称和路径翻译为适当的语言
• 可能有助于用户更好地导航（例如，我怀疑不同的命名文件夹可能会减少对作者在蓝图中的位置的混淆）

一种方法 为了使引用“内容Porter友好”，至少对于模板构建块，我知道我们可以在组件中使用WebDAV URL，确保将每个路径定位到子出版物中的正确位置。例如：

代码检查发布元数据

发布元数据指向“配置组件”

配置组件的路径为WebDAV URL

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

问题

• 我做对了吗？有更简单或更容易维护的设置吗？

我相信我们也可以使用includes或

• 任何人都有

  #include

  方法的例子吗？我是否在TBB和/或DWT的顶部使用该方法，并且引用是否会被替换而不考虑模板中介（例如，这是否适用于XSLT中介、Razor中介等）

• 包含的参考资料在较低版本的出版物中有效吗？还是仅用于内容波特？换句话说，如果我引用“tcm:5-123”，模板是否正确引用出版物17中的“tcm:17-123”

---

尽管我们通常将模板类型实现称为模板中介，但这并不是全部。模板类型实现既包括模板中介，也包括模板中介，尽管后者是可选的。给定的实现是否正确地处理“includes”不取决于中介，而是取决于处理程序

可以通过搜索

AbstractTemplateContentHandler

找到文档中的一个良好起点

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

由于这是SDL Tridion的一个扩展点，所包含的引用在较低版本的出版物中是否“正确”工作取决于实现者对其含义的看法

---

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

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

在任何东西中使用TCM ID都没有唯一有效的理由——模板代码、配置组件、配置文件

如果在配置中需要webdav URL，我会尝试始终将它们设置为“相对”，通常从“/Building%20Blocks”开始，而不是发布名称。在运行时，我可以使用

Publication.WebDavUrl

或

PublicationData.LocationInfo.WebDavUrl

获取URL的其余部分

Tridion知道如何处理托管链接，因此尽可能多地使用它们。（托管链接是TridionXML中随处可见的

xlink:href

内容）

---

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

使用绝对webdav URL也是完全合法的。通常，您在配置时就知道该项位于哪个发布中。