Как реализовать чистку кэша шаблонизатора?

QQQ

Новичок
Как реализовать чистку кэша шаблонизатора?

Есть шаблонизатор. Он генерирует html на основании массива, полученного от контроллера, который контроллеру был возвращаён моделью. Шаблонизатор умеет кэшировать куски сгенереного html.

Вопрос: как лучше привязать систему кэширования шаблонизатора к моделям, чтобы при изменении данных в другом месте приложения, чистился бы html кэш?

В идеале, при наличии кэша не требующего обновления (не было изменений данных, из которых он генерировался), контроллер даже не должен создавать модель и получать от неё массив.

Вот как всё это дело лучше связать? Накидайте плз вариантов реализации у кого есть или сцылок, где можно почитать о том, как это обычно делают.
 

MiksIr

miksir@home:~$
В идеале, при наличии кэша не требующего обновления (не было изменений данных, из которых он генерировался), контроллер даже не должен создавать модель и получать от неё массив.
Мы базировались на URI. Блочное кеширование собиралось через SSI подзапросами, соответственно имело тоже свои URI. Такая схема позволяет ловить кеш на уровне веб-сервера и не доходить запросу до PHP вообще.

Вопрос: как лучше привязать систему кэширования шаблонизатора к моделям, чтобы при изменении данных в другом месте приложения, чистился бы html кэш?
В общем идея была такая (до конца на практике не проверилась, ибо кончилось бабло). Модель при использовании регистрирует себя в в неком прикладном классе (в нашем случае это должен делать датамапер). По окончании обработки запроса список использованных моделей ставится в зависимость от URI запроса и сбрасывается в реестр. Таким образом при изменении модели есть возможность взять список всех сгенерированных страниц с ее использованием и очистить.
Хотели еще привязываться не только к модели, но конкретно к записи, но тут вылезает много сложностей, прорабатывать которых времени не было (например, постраничный вывод).
 

zerkms

TDD infected
Команда форума
Как говорится, в программировании 2 самых важных проблемы: инвалидация кэша и придумывание имён для переменных :)
 

weregod

unserializer
согласно http://www.php.net/manual/en/language.variables.basics.php

> '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*'

> Note: For our purposes here, a letter is a-z, A-Z, and the bytes from 127 through 255 (0x7f-0xff).

то есть 1с-программисты могут и в похапэ оторваться ;)
 

Alexandre

PHPПенсионер
Как говорится, в программировании 2 самых важных проблемы: инвалидация кэша и придумывание имён для переменных :)
да, придумать удачное умя - оказывается действительно не так просто...
инвалидация кеша: я запускаю фоновую задачу - которая обходит кеш и смотрит дату последнего обращения к файлу кеша. Если оно менее заданного time()-limit, то файл прибиваю.
 

Вурдалак

Продвинутый новичок
Автор оригинала: Alexandre
инвалидация кеша: я запускаю фоновую задачу - которая обходит кеш и смотрит дату последнего обращения к файлу кеша. Если оно менее заданного time()-limit, то файл прибиваю.
— это ж не решение... Данные могут быть сто раз неактуальными, но всё ещё «висеть» в кеше.
 

whirlwind

TDD infected, paranoid
Если бы передо мной стояла такая задача, я бы сделал по схеме MiksIr через события на датамапперах. При селектах отмечать например в таблице: класс, id, url. При апдейтах/делейтах тыркать кэш что бы по урлу чистил. Если датамапперы в фабрике, то можно прикрутить вообще не трогая рабочий код: декорируем фабрику и подписываем каждый датамаппер после инстанцирования.
 

Alexandre

PHPПенсионер
Данные могут быть сто раз неактуальными, но всё ещё «висеть» в кеше.
ну и пусть себе висят, кому они мешают? - cleaner их со временем прибьет. А вот Дима (whirlwind) правильно заметил, в случае update/insert кеш надо прибивать. Все конечно от задачи зависит: для блогов это актуально, для шопа - нет. У меня что-то типа шопа. Прибиваю при закачки нового контента.
 
Сверху