我们经常需要 Tridion 相关代码中的特定项目(模式、模板或组件)。模板、内容交付、工作流或业务连接器(核心服务)经常需要对Tridion Content Manager URI的引用。我们可以链接到组件,但我通常会看到硬编码的值或其他所有内容的 WebDAV URL。
硬编码值
我了解硬编码 Tridion Content Manager (Native) URI 是一种不好的做法,除了以下几种情况:
- 简化示例代码并明确变量是什么
- 生成用于内容交付 (CD) API 逻辑时
只要有可能,我们就使用给定的 API 或 WebDAV URL 来引用项目,否则我们必须避免在任何引用 TCM URI 的东西上使用 Content Porter(或者以某种方式使这些引用在 Tridion 之外“可配置”)。
WebDAV URL
WebDAV URL似乎更好,原因如下:
- 设计模板构建块 (TBB) 或其他模板格式中的硬编码值在 SDL Content Porter 中保持不变(在 CMS 环境中移动时会破坏关系,下面描述的例外情况)
- 引用特定项目的“配置”组件在使用 SDL Content Porter 时也做得更好,尽管不同名称的路径可能会“破坏”关系
用例
除了拥有与 Content Porter 配合良好的模板外,我还想在较低的出版物中本地化文件夹和/或结构组。这可以帮助:
- 阅读不同语言的 CMS 作者
- 将项目名称和路径翻译成适当的语言
- 也许可以帮助用户更好地导航(例如,我怀疑不同名称的文件夹可能会减少作者在蓝图中的位置的混淆)
一种方法
至少对于模板构建块而言,要使引用“内容搬运器友好”,我知道我们可以在组件中使用 WebDAV Urls,以确保将每个路径本地化到子出版物中的正确位置。例如:
- 代码检查发布元数据
- 发布元数据指向“配置组件”
- Config 组件的路径为 WebDAV URL
只要我们设置发布元数据并将字段本地化到每个发布的正确路径,这将适用于大多数情况。
问题
- 我做对了吗?是否有更简单或更易于维护的设置?
我相信我们可以选择在模板代码中使用包含或映射非托管 URI。
有人有这种
#include
方法的例子吗?我是否在 TBB 和/或 DWT 的顶部使用它,并且无论模板中介者如何,引用都会被替换(例如,这将与 XSLT 中介者、Razor 中介者等一起使用吗?)包含的参考资料是否适用于较低的出版物,还是仅适用于 Content Porter?换句话说,如果我引用“tcm:5-123”,模板会在出版物 17 中正确引用“tcm:17-123”吗?