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, или какой-либо другой политике сайта), одним из решений является создание некоторого "суперпакета", который мог бы иметь явные знания об этих цепочках обновлений. Но есть ли другие решения, кроме того, чтобы всегда придавать итоговый профиль политике?

(Для простоты давайте забудем, что некоторые изменения могут быть сделаны через Интернет)

Источник

2 ответа

Решение

Решили использовать нестандартное решение с вспомогательными функциями, чтобы облегчить общую задачу обновления. Не решает всех проблем, но помогает развертыванию.

Источник

Это на самом деле уже в GS, хотя, к сожалению, это не то, что все продукты используют. Решение заключается в использовании GS upgradeStep,

Скажем, вы изменили метаданные профиля с версии 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"
      />

В one_to_two.py вы бы тогда

def upgrade(context):
    registry = getUtility(IRegistry)
    if 'foo' in registry:
        do_stuff()

Там вы также можете перезапустить определенные шаги импорта, например:

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

При обновлении продукта будет применяться только то, что указано в обработчике шага обновления, и это именно то, что вам нужно.

Документация на все это здесь.

Источник
Другие вопросы по тегам