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

Question

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

硬编码值

我理解硬编码Tridion Content Manager（Native）URI是一种不好的做法，除了几个场景：

• 简化示例代码并明确变量是什么
• 生成用于Content Delivery（CD）API逻辑时

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

WebDAV URL

WebDAV URLs似乎更好，原因如下：

• 设计模板构建块（TBB）或其他模板格式中的硬编码值与SDL内容移植器保持完整（在CMS环境中移动时断开关系，下面有例外）
• 引用特定项目的“配置”组件在SDL内容移植器中也做得更好，不同命名的路径可以“破坏”关系

用例

除了具有与Content Porter兼容的模板之外，我还想在较低的出版物中本地化文件夹和/或结构组。这有助于：

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

一种方法

为了使参考“内容易于使用”，至少对于模板构建模块，我知道我们可以在组件中使用WebDAV Url，确保将每条路径本地化到子出版物中的正确位置。例如：

1. 代码检查发布元数据
2. 发布元数据指向“配置组件”
3. 配置组件的路径为WebDAV URL

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

问题

• 我说得对吗？是否有更简单或更易于维护的设置？

我相信我们也可以使用包含或map unmanaged URI in template code。

• 任何人都有#include方法的示例？我是否在TBB和/或DWT的顶部使用它，并且无论模板介体如何都会替换引用（例如，这适用于XSLT Mediator，Razor Mediator等吗？）

• 包含的参考文献是否适用于较低的出版物，或仅适用于内容移植者？换句话说，如果我引用“tcm：5-123”，模板将正确引用“tcm” ：17-123“出版物17？

Answer 1

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

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

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

Answer 2

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

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

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

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

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