Tridion 需要获取组件的XML'；那是出版的版本吗

我们正在Tridion2011中的一个文件夹中迭代组件，并根据组件的发布状态创建用于CD的自定义XML。下面我举一个例子，让你们理解这个问题

支持我们在一个文件夹中有10个组件，这些组件都已发布，我们发布XML，然后生成10个项目的XML

现在，我们在其中一个组件中进行更改，而不发布它

修改组件后，我们再次发布XML。然后，修改后的组件的XML也会得到更新。因此，它在该组件的发布版本和XML中的版本之间创建了差异

因此，我希望以这样一种方式发布自定义XML，即它应该只包含与已发布的组件版本同步的数据

那么你想：

确定上次发布的组件的XML

确定该XML与组件的当前XML之间的更改

仅发布更改

Tridion不跟踪发布的版本（至少在Content Manager上）。因此，您所能做的最接近的事情就是找出组件上次发布的时间，并检索当时的XML。这是关于该方法的更多信息的一个很好的起点。基于该XML，您可以执行上面的步骤2和步骤3

或者，您可以在呈现组件时保留“某处”（例如在应用程序数据中）发布的XML的快照。然后，当组件下次发布时，您可以检索该XML并执行上面的步骤2和步骤3

---

请注意，对于这些解决方案中的任何一个，您都应该真正想知道是否应该从一开始就实施它。您正在覆盖Tridion的一些默认呈现行为，并绕过其架构的一部分（内容管理和内容交付之间明确、明确的分离，前者对后者一无所知），您所做的任何事情都会及时困扰您。在这个用例中，您必须想知道当CD和TCM不同步时会发生什么。简单地突然重新发布内容已经不够好了，因为您的代码将在其中决定“自上次发布以来没有任何更改，因此我们将不发布任何内容”。

那么您的解决方案是

在发布事务保存事件上编写事件处理程序

将发布信息（版本数据）保存到已发布组件的应用程序数据

我之所以提到Publish Transaction Save（发布事务保存）事件，是因为您可以从中确保仅在事务成功时保存发布信息

还要注意，当事件处理程序无法执行时，此发布信息可能会失去同步，并且在移动到其他环境时可能会丢失所有应用程序数据

---

因此，当这些信息非常重要时，我会将其保存到一个单独的数据库中，而不是应用程序数据。

如果我仓促下结论，请原谅，但我强烈感觉这个问题是由于对Tridion缺乏了解而产生的。在Tridion中发布不仅仅是升起一个标志，表明该项目已“发布”，换句话说，准备向外界展示。我知道一些（许多）内容管理系统就是这样运行的（这可以解释为什么你会问这个问题）。 然而，在Tridion中，发布意味着项目实际上从内容管理环境物理地转移到了内容交付环境。此环境始终包含表示项目上次发布时状态的内容版本，这仅仅是因为正是发布行为创建了这些版本

---

在我看来，您真正要问的是如何重建此发布功能。这绝不是一个好主意。相反，您应该认真对待Bart的评论，并查看Tridion提供的一个内容交付API（代理API或ODataWeb服务）。或者，您可能希望查看DD4T，它构建在代理之上，并公开完整的Tridion数据模型。

>“我希望以这样一种方式发布自定义XML，即它应该只包含与已发布的组件版本同步的数据。”-您是说要禁用内容更新吗？您的问题不太清楚，您使用的是什么发布模式？如果您的内容进入动态内容代理，您可以从代理中获取已发布的内容，而不是试图从内容管理器中获取。为此，您可以使用代理API甚至ODataWebService（如果已安装的话）。我想确定上次发布的组件的XML，并在此基础上创建XML。我不需要在意那些尚未发布的更改。第一点是我的确切要求。我想在CMS部件上执行此操作。Tridion没有现成的：

项。ContentAsLastPublishedToTarget（targetId）

方法。因此，我为您提供了两种可能的方法来确定此XML：根据上次发布的时间戳查找它或在发布期间存储快照。应用程序数据存储在CMS数据库中，在Content Porter 2009 SP2中也将进行移植，因此根据不同环境的同步方式，也可以将应用程序数据保存在那里。但是我仍然想知道这是否应该在CM端实现，从收集的信息来看，这听起来更像是CD端的要求，正如Frank在最后一段中指出的那样。我不认为这是CD端的要求。他可能想发布某种类型的列表，并且只包含作为嵌入页面的一部分发布的组件的版本。但是，对于这些背景有限的问题，很难弄清楚目的到底是什么（我们正在使用事件自动发布