Фрагментарное кэширование в MVC веб-фреймворках

Вообще с точки зрения MVC получается правильно: View посредством run просит отдать ему данные.
Интересный пример, над которым стоит подумать. Правда субъективно, хочется что-то более элегантное.
Спасибо за решение :)

Спасибо, вроде все чисто. Надо бы перечитать как-нибудь, а то пока голова не варит :-)

Меньше-кода, больше-дела, вот это хорошо, спасибо, хорошая статья.

Хотите элегантное решение? Оно есть в symfony. Использование компонентов. Мы просто берем и весь фрагмент указываем как компонент. Компонент это такой мини-контроллер, который сам по себе не запускается, а лишь выдает фрагмент, который встраивается на страницу. Кешировать его можно просто как и обычные фрагменты шаблонов.

Короче, нефиг придумывать велосипеды :)
+ из этитх реализаций мне больше всего нравится реализация через модель. Она самая простая.

http://zendframework.com/manual/ru/zend.…

есть такой "фронт энд" Zend_Cache_Frontend_Output
+есть еще и другие "фронт энды"
+в Zend_Cache есть еще понятие бэк эндов, т.е. способов хранения кэша например файл, Memcached, sqlite...
+теги к записям, позволяют гибко управлять очисткой кеша.

На мой взгляд, кэширование SQL запросов как в Рельсе 2, не всегда спасет.

Ведь изменение в БД может производить не только приложение на рельсе, которое управляет и кэшем - к БД может подключаться и стороннее приложение, которое будет вносить изменения в БД, а рельса не будет об этом знать.

Спасибо.

а почему бы не разбить шаблон на блоки, где каждый блок будет иметь контроллер и шаблон? тогда кешировать можно на уровне блоков.

Насколько я понял основная фишка здесь паттерн Lazy load (или как-то похоже называется). То есть мы в шаблон передаем не данные, а указываем как их получить. А получаются они только в момент реального использования, то есть при работе с темплейтом.

Посмотрите пожалуйста http://framework.zend.com/manual/en/zend…

Вы это хотите реализовать?

function test()
{
if(!$content = $this->CI->cache->load('top_news', 60*60))
{
$this->CI->view(shablon) - К примеру

$this->CI->cache->save($content, 'top_news');
}
return $content;
}

Получаем нужный результат, все происходит до выполенения View.

Класс за основу брал отсюда: http://larin.in/archives/11

Фундаментальная проблема - это то, что контроллер никак не может добраться до этого блока, чтобы "контролировать" его.
Мой концепт (action-controller)

...
$this->page()->getLayout()->getLayout()->getBlock('spisokTovarov)->аВотТутМожноВсе();
...
или:
$this->page()->getLayout(2)->getBlock('spisokTovarov)->аВотТутМожноВсе();

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

Из замечаний: со статическими вызовом перемудрили, не нужно никаких двух двоеточий, call_user_func умеет принимать на вход массив, в котором первый элемент строка, а не объект - тогда он делает вызов статической функции.

А вообще, спасибо за идею.

все круто но само по себе кеширование кусков кода или результатов функций это просто

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

да и вообще КЭШИРОВАТЬ НУЖНО НЕ КУСКИ VIEW а куски данных которые нужны для вью, которые собираются контроллером, кэширование вью это отдельная ступенька

У меня, например, сделано так: кэшируются выборки из базы. Каждая выборка- отдельный объект, который может быть поименован согласно того что именно выбирается (это делается как правило на уровне модели), т.е. контроллер спрашивает у модели "записи пользователя 1", модель возвращает выборку и именует ее. Именование идет каскадно. Соотв. по имени можно сбросить все связанные кэши.

Если очень хочеться закэшировать html, то у меня это реализовано приблизительно следующим образом:
1. Выборка передается в шаблон, шаблон пробегается по ней в цикле, при этом непосредственно запрос к БД/кэшу происходит on-demand.
2. Если мы кэшируем какой-то участок шаблона- если кэш не найден, запоминаются все имена произведенных выборок, после чего запоминаем в кэше собствено html и связи с именованными выборками.
3. При изменении модели она сбрасывает все кэши с некоторым именем, как кэши выборок, так и непосредсвенно html.

Сам вызов кэша в шаблоне реализован как активный тег поэтому выглядит все как-то так:
контроллер

$sel= new items_select();
$sel->Where('UserID',eq,$UserID);
//Имя кэша:
$sel->setCacheName('user_items_'.$UserID);
//Постраничный вывод:
$sel->Limit((int)$_REQUEST['page']*10,10);

Шаблон:
(тупо делаем имя по строке запроса)

<!-- op:cache="user_items_{$_SERVER.REQUEST_URI}" lifetime="1000"-->
<!--op:each="$sel"-->
<a href="{$Link}">{$Title}</a>
<!--/op:each-->
<!--/op:cache-->


Написал подробную статью о том как устроены шаблоны Django и как в Django решается сабж.