tridion - 避免在 Tridion 相关代码中使用硬编码的 TCM URI

Question

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

硬编码值

我知道硬编码 Tridion 内容管理器( native )URI 是一种不好的做法，除了以下几种情况:

为了简化示例代码并明确什么是变量

生成用于内容交付 (CD) API 逻辑时

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

WebDAV URL

WebDAV URLs由于以下几个原因，似乎更好:

设计模板构建块 (TBB) 或其他模板格式中的硬编码值与 SDL Content Porter 保持一致(在通过 CMS 环境移动时破坏关系，下面描述的异常(exception)情况)

引用特定项目的“配置”组件也能更好地使用 SDL Content Porter，但不同名称的路径可能会“破坏”关系

用例

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

阅读不同语言的CMS作者

将项目名称和路径翻译成适当的语言

也许可以帮助用户更好地导航(例如，我怀疑不同名称的文件夹可能会减少作者在 BluePrint 中的位置的混淆)

一种方法

为了使引用“内容搬运工友好”，至少对于模板构建块，我知道我们可以在组件中使用 WebDAV Urls，确保将每个路径本地化到 child 出版物中的正确位置。例如:

代码检查发布元数据

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

配置组件的路径为 WebDAV URL

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

问题

我做对了吗？是否有更简单或更易于维护的设置？

我相信我们可以选择使用 包括 或 map unmanaged URI in template code .

任何人都有一个 #include 的例子方法？ 我是否在 TBB 和/或 DWT 的顶部使用它，并且无论模板介体如何，引用都会被替换(例如，这是否可以与 XSLT 介体、Razor 介体等一起使用？)

所包含的引用文献是否适用于较低的出版物，还是仅适用于 Content Porter？ 换句话说，如果我引用“tcm:5-123”，模板是否会在出版物 17 中正确引用“tcm:17-123”？

Answer 1

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

在任何事物中使用 TCM ID 都没有单一的正当理由——模板代码、配置组件、配置文件。

如果我在配置中需要 webdav URL，我会尽量使它们“相对”，通常从“/Building%20Blocks”而不是发布名称开始。在运行时我可以使用 Publication.WebDavUrl或 PublicationData.LocationInfo.WebDavUrl获取 URL 的其余部分

Tridion 知道如何处理托管链接，因此请尽可能多地使用它们。 (托管链接是您在 Tridion XML 中经常看到的 xlink:href 内容)。

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