我们在Tridion 2011中的文件夹中迭代组件，并根据组件的发布状态创建我们的自定义XML以用于CDS。我给出下面的例子来让你理解这个问题。需要获取已发布版本的组件的XML
因此，我想发布自定义XML，使其只应包含与发布的组件版本同步的数据。
所以，你想：
Tridion不会跟踪发布的版本（至少在内容管理器上）。所以最接近你可以做的是找出当组件上次发布并检索当时的XML。 This question是关于该方法的更多信息的一个很好的起点。基于该XML，您可以执行上面的步骤2和3。
或者，您可以在渲染组件时保留您在“某处”（例如在应用程序数据中）发布的XML快照。然后，当组件下次发布时，您可以检索该XML并执行上述步骤2和3。
请注意，对于任何这些解决方案，您应该真的想知道是否应该开始实施它。您正在重写Tridion的一些默认渲染行为，并绕过其架构的一部分（内容管理与内容交付之间明确的断开，前者对后者不了解），并且您做的任何事情都会回来困扰您时间。在这种用例中，您不得不想知道当CDS和TCM不同步时会发生什么。只是简单地重新发布内容已经不够了，因为你的代码会在那里决定“自从上次发布以来没有任何变化，所以我们什么都不会发布”。
第1点是我的确切要求。我想在CMS部分上做。 – AlokBhatt 2012-07-24 06:01:03
Tridion没有现成的：'item.ContentAsLastPublishedToTarget（targetId）'方法。因此，我给了你两种可能的方法来确定如何确定这个XML：按照LastPublished时间戳查找或在发布期间存储快照。 – 2012-07-24 11:00:47
那么你的解决方案是
我提到了“发布事务保存”事件，因为从那里您可以确保只有在事务成功时才会保存发布信息。
另请注意，当事件处理程序执行失败时，此发布信息可能不同步，并且在移至其他环境时可能会丢失所有应用程序数据。
所以当这些信息是绝对重要的时候，我会把它保存到一个单独的数据库中，而不是应用程序数据。
应用程序数据存储在CMS数据库中，而在Content Porter 2009 SP2中，它也将被移植，因此根据不同环境的同步方式，应该可以将应用程序数据保留在那里。但是我仍然想知道这是否应该在CM方面实施，从收集的信息来看，这听起来更像是一个CD方面的要求，Frank也在他的最后一段中提到了这一点。 – 2012-07-24 07:50:38
我不认为这是CD方面的要求。他可能想要发布某种类型的列表，并且只包含已作为嵌入页面中的一部分发布的组件版本。但是对于这些背景有限的问题，很难弄清究竟是什么目的。 :( – 2012-07-24 09:43:47
请原谅我，如果我妄下结论，但我强烈认为这个问题是由于缺乏对Tridion的理解而产生的。在Tridion出版不仅仅是举起一面旗帜来表明该项目是“已发布”的，换句话说就是准备向外界展示。我知道这是一些（很多）内容管理系统如何运作（这可能解释你为什么要问这个问题）。 但是，在Tridion中，发布意味着该项目实际上是从物理管理环境转移到内容交付环境。此环境始终包含代表项目上次发布时的状态的内容版本 - 仅仅是因为这是创建它们的发布行为。
在我看来，你真正要问的是如何重建这种发布功能。这绝不是一个好主意。相反，您应该认真对待Bart的评论并查看Tridion提供的内容交付API之一（代理API或OData Web服务）。可选地，您可能想要查看构建在代理之上的DD4T，并展示完整的Tridion数据模型。
>>“我想发布自定义XML，使其只应包含与发布的组件版本同步的数据” - 您是否说要禁用内容更新？ – 2012-07-23 15:11:02
你的问题不太清楚，你使用的是哪种发布模式？如果您的内容进入动态内容代理，则可以将发布的内容从代理中取出，而不是尝试从内容管理器中获取内容。为此，您可以使用Broker API或者oData webservice（如果已安装）。 – 2012-07-23 15:36:42
我想确定上次发布的组件的XML，并在此帮助下创建XML。我不需要照顾尚未发布的更改。 – AlokBhatt 2012-07-24 05:58:54