Plone 4需要更智能的通用设置更新

问题的核心是，GenericSetup配置文件是可添加的。有时，产品不能通过简单地应用概要文件来升级，整个概要文件链需要按特定顺序应用

例如，假设我们有很多独立的站点策略（只应用其中一个） 对于plone实例）：S1、S2、…、SN。还有一些产品，比如a和B。例如，所有这些S1-SN、a和B都有元数据依赖关系，如下所示：SN->a->B

假设它们处理registry.xml，并在此过程中重写某些内容。（typeinfo和其他一些配置文件步骤的情况也是如此）。如果产品A中的某些更改（可能在S1中被覆盖，也可能不被覆盖），我们不能仅为A执行升级步骤，因为当我们在S1站点上按下按钮时，其自身的策略覆盖将丢失。然而，为所有S1-SN编写升级步骤是一件大事，因为a中出现了变化

至少在上面描述的情况下，当整个问题可以通过按特定顺序应用注册表更新来解决时，是否有任何明智的方法来进行升级，即：B、A、Sn。（即使这样，也可能会有一些困难的情况）

由于包A不知道S1（或S2或任何站点策略），一个解决方案是制作一些“超级包”，可以明确了解这些升级链但除了始终将结果配置文件放入策略之外，还有其他解决方案吗？

---

（为了简单起见，让我们忘记一些更改可以通过web完成）

这实际上已经存在于GS中，尽管并非所有产品都使用它。 解决方案在于使用GS的

升级步骤

假设您将配置文件的元数据从版本1更改为版本2。在zcml中，您注册了如下升级步骤：

  <genericsetup:upgradeStep
      title="Upgrade myproduct from revision 1 to 2"
      description=""
      source="1"
      destination="2"
      handler="myproduct.one_to_two.upgrade"
      sortkey="1"
      profile="myproduct:default"
      />

在其中，您还可以重新运行特定的导入步骤，例如：

context.runImportStepFromProfile('profile-myproduct:default','actions')

升级产品时，只应用升级步骤处理程序中指定的内容，这正是您所需要的

---

关于所有这些的文档。

决定使用自定义解决方案，使用帮助函数使常见的升级任务更容易。无法解决所有问题，但有助于部署。

当然，我知道升级步骤。请重新阅读问题陈述。引述：“……我们不能只为一个站点执行升级步骤，因为当我们按下S1站点上的按钮时，它自己的策略覆盖将丢失。”

context.runImportStepFromProfile('profile-myproduct:default','actions')