Главная Библиотека CMS Plone Подписи под изображениями и кэш PortalTransforms

Подписи под изображениями и кэш PortalTransforms

Проблемы и решения. Перевод статьи "Image captions and the PortalTransforms cache", автор David.

Plone 3 содержит замечательную возможность, посредством которой изображения, вставленные в kupu, могут автоматически приобретать заголовок с тем же названием, которое уже присвоено сохраненному изображению. Однако, если Вы уже пробовали пользоваться этой функцией, Вы, возможно, заметили, что если Вы измените заголовок, и затем зайдете на страницу с этим изображением, то подпись обновится только примерно через час.

Причина связана с тем, как подписи добавляются через  преобразование html в заголовок (html-to-captioned), которое применимо к любому содержимому с text/x-html-safe выводом MIME-типа, благодаря специальной политике преобразования, сконфигурированной для этого MIME-типа. Получается, что PortalTransforms кэширует результат преобразования в течение часа. Он сохраняет этот результат во временном значении атрибута, который будет потом трансформирован, поэтому, обычно, когда Вы редактируете и полностью заменяете это значение, Вы не должны волноваться об аннулировании кэша. Это означает, что при сохранении нового текста для страницы, старый будет удален, и мы увидим новый текст в следующий раз, когда откроем страницу. Однако, в случае редактирования заголовка изображения Вы сохраняете совершенно иное значение и в другое место, нежели то, где хранится старый вариант. Поэтому, даже если Вы перезагрузите страницу, Вы увидите старый заголовок.

Обходной маневр 1: Изменение настройки времени кэш

Вариант 1: Зайдите в /portal_transforms/manage_cacheForm в ZMI, и установите меньший промежуток времени для cache lifetime. Но помните, что это отрицательно повлияет на производительность (особенно для часто просматриваемых страниц, но не выделенных из прокси-сервера), поскольку придется чаще делать преобразование.

Обходной маневр 2: Аннулируйте вручную кэш после редактирования заголовка изображения

Вариант 2: Когда вы заменили заголовок изображения, аннулируйте кэш в местах ссылок на изображение. Я сделал так впервые при выполнении текущего проекта. Для этого проекта у меня есть  пользовательский дочерний объект ATImage, и изображения всегда содержатся в рамках (folderish) статьи, поэтому я изменил caption mutator следующим образом:

def setCaption(self, value, **kw):
    self.getField('caption').set(self, value, **kw)

    # The result of transforms is cached for up to one hour.
    # Our caption is inserted into article text via a transform,
    # so if we're located within an article, invalidate the
    # (volatile) cache of the article's text.
    parent = aq_parent(aq_inner(self))
    if IArticle.providedBy(parent):
        value = parent.getField('text').getBaseUnit(parent)
        if hasattr(value, '_v_transform_cache'):
            delattr(value, '_v_transform_cache')

(Примечание: я впервые исследовал использование класса Cache продуктов PortalTransforms.cache, на возможность выполнять Cache(value).purgeCache() … однако, в текущем релизе PortalTransforms, метод purgeCache использует метод, который не был импортирован, поэтому я лишь воссоздал то, что он выполняет. Я сделал поправку в исправлении к PortalTransforms, которая должна войти в следующий выпуск пакета.)

Для более общего внедрения аннулирования кэша, Вы могли бы захотеть это сделать в хендлере для события IObjectEdited на ATImages, и использовать независимо от того, что делает код linkintegrity (проверки целостности ссылок), чтобы определить, какие элементы содержат ссылки на редактируемые изображения, и, поэтому являются кандидатами на удаление из кэша. (Аннулирование кэш необходимо только в том случае, если поле ссылки было уже предоставлено и находится все еще в памяти кэша ZODB, поэтому, конечно же, было бы неплохо удостовериться, что аннулирование кэш не приведет к появлению дополнительных объектов.)

У меня нет необходимости, времени и интереса продолжать эту работу самостоятельно, но было бы неплохо, если кто-нибудь занялся этим. :) Возможно у кого-нибудь из Вас также есть варианты по данному вопросу…

Оригинал статьи на david.wglick.org

Перевод ООО «Комтет» komtet.ru

Другие документы на эту тему