Кэширование виджетов и сайтбаров
24.10.2009Одним из центральных классов блоголёта является ttemplate, который собственно и генерирует конечный html, с необходимыми внутри php вставками. Начав выделять из этого класса новый класс twidgets для управления виджетами, задумался, не выделить еще один класс tsitebars для управления сайтбарами? Точнее виджетами внутри сайтбаров. И вдруг понял - а почему кэшируются только виджеты, а не сам сайтбар? Чтобы получить готовые сайтбары приходится включать около 10 виджетов, даже если все виджеты закешированы, то все равно требуются ресурсы для открытия файла. Когда как логичнее было бы кэшировать весь сайтбар. Итого с борта будет сброшено около 10 файлов при генерации страницы. Так что в новой версии блоголёта будут кэшироваться сайтбары. Кеширование для виджетов останется, но только для виджетов с типом include, а обычные с типом echo не будут кэшироваться, а единоразово генерироваться и включаться в сайтбар.
Одним из трюков/фич в реализации класса виджетов будет способ хранения данных - в базовом классе ttemplate. По умолчанию каждый класс блоголёта имеет свои, независимые от других классов данные. сейчас мне кажется, что это будет оптимальным, хранить данные в одном классе. С другой стороны если генерация сайтбара будет не частой процедурой, и поднятие класса twidgets будет происходить редко, то в принципе можно и не хранить эти данные в ttemplate. Этот пост я писал затем, чтобы самому разобраться - нужен ли отдельный класс tsitebar, и где хранить данные.
Также скорее всего будет вычленен еще один класс с пока условным именем tthemeparser - разборщик тем. Файлы темы будут парситься при ее смене. Соответственно держать вес набор функций по разбору файлов тем в базовом классе ttemplate не имеет смысл. Быть может будет класс tthememanager, с дополнительными опциями (пока неизвестными мне самому).
Комментарии (7) на запись “Кэширование виджетов и сайтбаров”
Оставить комментарий
>>Файлы темы будут парситься при ее смене
ИМХО в принципе лишняя, но удобная сущность при разработке темы - кнопка "перечитать тему", ну или перепарсить
И вопрос - может уже было пока не нашел, а код еще весь не облазил - какие-либо условные выводы на данный момент предусмотрены: по типу is_single, или как в Друпал - условия на url?
Если имеется в виду темы, то нет. Страница генирируется объектом, по простому сопоставляется урл к классу, который и генерирует html, как правило через ttemplate
А где изачем возникла эта надобность?
И если я кое-какие выводы подправлю /мне Lite режим не нравитьсяю там нужна таки шапка нормальная, с названием категории, тега или периодом а не Список записей за / - исправления посылать через контакты?
Задачу единственного виджета на главной можно решить несколькими путями, и мне сейчас сложно сказать, какой из путей наиболее простой или правильный. За главную страницу отвечает класс THomepage, и с одной стороны логично было бы добавить туда виджет. Но проблема с иддеей виджетов как таковых: блок контента в сайтбаре на каждой странице, в заранее известном порядке. Если делатьвиджет для одной странице, то сама функция генерации виджета будет дергаться на каждой странице, когда как логика прямо говорит, что это следует делать только один раз. Требуется либо переосмысление самой концепции сайтбаров/виджтов, либо придумать дополнительный алгоритм/сущность для разруливания этой ситуации. Пока у меня нет красивого решения, ну то есть решения при котором код генерации виджета дергался бы только один раз.
Что посоветуешь? Ввести новую сущностть динамический виджет? Добавить новое событие после генерации/включения виджета? Ну то есть не добавлять событие, а скажу так - добавить еще один метод в классе, который бы дергался после вставки сайтбара, а при отсутствии этого метода ничего бы не происходило. То есть расширить набор функций в ITemplate - смотри файл lib/interfaces.php Например придумать еще что то типа IAdvancedTemplate, и в случае его поддержки дергать соответствющие методы, как например сейчас проверяется наличие метода AfterTemplated в lib/templateclass.php
Так и сделаю - сделаю дополнительный интерфейс и в случае его поддержки дергать спец методы для обслуживания контента в соответствующих местах, а именно (что сейчас на ум приходит): до и после каждого виджета, до и после генерации всего контента, до и после меню секция head. Вообще то до до генерации контента дергается метод request(), до и после контента самого классса не стоит - пусть он внутри себя разруливает до и после,, а вот остальное можно.
есть разные сущности - полностью кешируемый виджет - который генерируется 1 раз на сайт, постраничные виджеты (кешируемые вместе со страницыми) и абсолютно некешируемые виджеты - которые каждый раз вызываются на исполненеие через include. Кстати как простое решение можно ввести 2 типа сайтбаров - сайтовые и страничные - с разными типами кеширования.
Сейчас следующая модель виджетов в блоголёте:
- сразу выводятся
- включаюттся через include (пример - свжие комментарии)
- каждый раз исполняются (пример сапа)
для одиночных виджетов подойдет новый интерфейс