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

Alv*_*yes 7 tridion

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

硬编码值

我理解硬编码Tridion Content Manager(Native)URI是一种不好的做法,除了几个场景:

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

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

WebDAV URL

WebDAV URL似乎更好,原因如下:

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

用例

除了具有与Content Porter一起使用的模板之外,我还想在较低的出版物中本地化文件夹和/或结构组.这有助于:

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

一种方法

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

  1. 代码检查发布元数据
  2. 发布元数据指向"配置组件"
  3. Config组件具有作为WebDAV URL的路径

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

问题

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

我相信我们也可以在模板代码中使用包含映射非托管URI.

  • 任何人都有这种#include方法的例子吗?我是否在TBB和/或DWT的顶部使用它,并且无论模板介体如何都可以替换引用(例如,这是否适用于XSLT Mediator,Razor Mediator等?)

  • 包含的参考文献是否适用于较低的出版物,还是仅适用于Content Porter?换句话说,如果我引用"tcm:5-123",模板会在出版物17中正确引用"tcm:17-123"吗?

Nun*_*res 6

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

  1. 在任何事物中都没有使用TCM ID的唯一正当理由 - 模板代码,配置组件,配置文件.
  2. 如果我在配置中需要webdav URL,我会尝试始终使它们"相对",通常从"/ Building%20Blocks"而不是发布名称开始.在运行时,我可以使用Publication.WebDavUrlPublicationData.LocationInfo.WebDavUrl获取URL的其余部分
  3. Tridion知道如何处理托管链接,因此尽可能使用它们.(托管链接是xlink:href你在Tridion XML上看到的东西).

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