【发布时间】:2013-01-09 07:55:02
【问题描述】:
我们要求页面的 url 需要本地化/翻译。我们现有的机制依赖于实际发布的 url 来通过 oData 检索页面。用一个简化的例子来澄清一下:我们在前端有一些逻辑,它接受请求 url(它没有文件扩展名,附加一个 .html 扩展名,例如:
/my-awesome-path/my-awesome-page
现在变成了
/my-awesome-path/my-awesome-page.html
然后逻辑使用查询从 oData 拉取页面
/odata.svc/Pages?$filter=url eq '/my-awesome-path/my-awesome-page.html'
我们有更多的逻辑来解析这个对 SEO 友好的 url 并获取 MVC 控制器函数参数和其他诸如此类的东西,但这与这里无关。
我们的要求是我们不能对页面进行本地化以为其提供翻译后的 url,因为这意味着无法在父网络出版物中管理整个页面。
要获得指向页面文件名的本地化路径,我们只需本地化 SG。困难在于页面文件名。在页面的元数据上,我们有一个链接的“可本地化元数据”组件,其中包含一个用于提供本地化页面文件名的字段。
我们想做的是在发布/部署过程中更新页面的 URL 属性,以使用来自此链接元数据组件的本地化页面文件名更新页面的已发布 url(假设我们可以访问本地化文件名字段的值在开始发布到承诺部署之间的任何阶段)。
我已尝试通过自定义解析器执行此操作,但是,在此级别上,页面.PublishedUrl 属性似乎已由 CM 建立并且不能被覆盖。所以更新 page.FileName 属性没有任何用处。
我还尝试将 Broker DB 中 PAGE 表中的 URL 列直接更新为不同的名称,并且似乎一切都在继续工作,包括动态链接和取消发布页面。显然写一个存储扩展或者部署扩展通过jdbc直接更新数据库是不可接受的。
以下是我正在考虑的选项: 1) 尝试部署器扩展并使用 Tridion API 更新 url 属性 2) 尝试编写一个自定义渲染器来执行 url 替换逻辑而不实际更新代理中的 url。我不赞成这样做,因为每次都需要请求时间处理。
我的问题是:更新页面 url 属性最合适的方法是什么?使用 Tridion API 编写自定义部署程序来更新 URL 属性是否会像 Resolver 那样让我陷入死胡同?
【问题讨论】:
-
我认为您可能不得不在部署者方面执行此操作。您可以使用部署程序扩展来更改传输包中页面的文件名(这里是dragons:未记录且可能不受支持)...
标签: tridion odata tridion-2011 tridion-content-delivery