У меня, например, сделано так: кэшируются выборки из базы. Каждая выборка- отдельный объект, который может быть поименован согласно того что именно выбирается (это делается как правило на уровне модели), т.е. контроллер спрашивает у модели "записи пользователя 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-->
Специально прочитал мануал по плагинам, я не очень понимаю как вывести определенный в шаблоне html код через по n в ряду через определенный в шаблоне разделитель, так чтобы не запихивать его в параметры функции.
Точнее это можно сделать через префильтр, но я уже писал, что приведенное решение- скорее препроцессор шаблонов, так что ничто не мешает использовать его как префильтр смарти. Я во-всяком случае так и собираюсь делать, как только разберусь как перегрузить вывод смарти.
Я знаю что XSLT может генерировать не XML документы, наверное я не точно сформулировал, он предназначен для генерации документа для одного "робота" (в данном случае компилятора) из документа от другого робота (EnterpriseArchitect). Т.е. в данном случае мы не можем визуализировать не исходные данные не полученные, поэтому нам в общем-то все-равно. Для HTML принципиальна возможность просмотреть.
Это хорошо, что они переопределяются, плохо то что они одинаковые для инструкций вывода и управления, e.c. если мы хотим завернуть циклы и условия в HTML комментарии для лучшей "просматриваемости" шаблона, то нам придеться завернуть и переменные, что во-первых увеличит энтропию вселенной, так как будет больше кода, а во-вторых мы при предпросмотре не увидим куда какая переменная вставляется.
Это, в принципе, и есть пункт 1, использование языка программирования в качестве шаблонизатора.
У Zend'а есть и свой шаблонизатор, идеологически больше всего напоминающий Blitz- вертим данными из контроллера.
Я такой писал года 3 назад, для интранет решений вполне хватало.
Спасибо, в хозяйстве пригодиться. Я когда свою базу воровал, пришлось распарсить википедию, проапгрейжу сегодня. Правда у меня структура более извращенная.
Я поэтому и сказал, что долго и муторно. В конторе, где я работал, был специальный человек, который этим занимался и получал определенную сумму с рассылки.
На самом деле, если с ними договориться, то можно рассылать, например, девочкам от 18 до 22, тратящим на мобильную связь более $10.
Правда договариваться долго и муторно.
Просто на самом деле, кроме френдленты, может быть еще куча выборок (по тегу например) и держать про запас в memcached'е еще десяток страниц на каждую IMHO несколько не экономно.
Хотя все зависит от ситуации.
Я так понимаю тебе UNION не нравиться? Хорошо делаем ход конем:
1. выделяем первые первые три бита маски под виртуальные группы: все, зарегистрированные, администрация
2. определяем нулевого (id=0) пользователя с отношениями для всех зарегистрированных пользователей (куча фейковых записей- бяка). Т.е.:
user_id ref_id mask
0 * 110...
Если запись "публичная" или "только для зарег" или "только администрация" то access соотв. буду 1,2 или 4, а us_id в records 0 (т.е. поле работает только для связи, идентификатор "владельца" будет дублироваться в другом поля.
Получаем выборку без UNION.
P.S. я не тестировал.
Да, конечно, все это как правило и делается.
Просто основной целью было получить выборку объектов с проверкой прав доступа на уровне выборки из базы.
Если надо вывести, например, постранично френдленту, то получается что надо выбрать n объектов, проверить права на чтение, выкинуть запрещенные и довыбрать еще, при этом постраничный вывод становиться очень нетривиальным так как мы не можем получить количество записей, а ссылки вида ←→ вычисляются динамически.
Просидев на фрилансе последние несколько месяцев, все-таки решил устроиться в офис. По следующим соображениям:
1. Свободный график- это, конечно, хорошо, но проблем в том, что нет четко обозначенного конца работы, когда можно расслабиться, получается кривой рабочий день, и каждый раз когда делаешь перерыв, ты вроде как сам у себя время крадешь.
2. Делаешь кучу левой работы, галочку передвинуть или еще что-то, для этого приходиться разбираться в чужом html, что не всегда тривиально, в результате убиваешь несколько часов на то, чтобы найти куда у тебя стрелочка делась.
3. Как уже сказали комментаторы выше, серьезных проектов гораздо меньше, и кроме того если, работая в нормальной конторе, ты можешь предложить сделать какую-либо интересную фишку, и, вполне вероятно, что ты ее будешь делать, то на фрилансе придеться либо делать ее бесплатно, либо муторно согласовывать ее стоимость.
4. По деньгам, честно говоря, за три-четыре месяца, ничего не понятно, кроме того активно я заказы не искал, так как параллельно занимаюсь еще проектом для себя "на перспективу".
Хотя, на самом деле, от фриланса отказаться было довольно сложно, сделал это так как устроился в контору, в которой есть возможность значительно повысить скиллы.
У меня кэширование идет на уровне модели, и кэшируются непосредственно данные.
Кэшировать html- хлопотно, так как он может различаться от пользователя к пользователю, кроме того у меня одни и те-же данные могут отдаваться в html и xml и в json- а узкое место именно доступ к бд.
Актуальность кэша- либо по времени жизни, либо через принудительное разрушение при обновлении (http://wiki.toukmanov.ru/dbSelect - тут подробнее, если интересно)
На каких-нибудь очень нагруженных страницах- вешаю тупой кэш html, отдаваемого модулем.
Был какой-то японский мультфильм, не помню как называется- в детстве смотрел, там был напиток боа джус, от которого люди растворялись.
Чем-то напоминает.
Либо ничего сделать не успели, либо решили оставить как есть. По значительной части адресов (все я поленился просмотреть), либо довольно унылые тематические каталоги, либо редирект на корпоративные сайты (тоже не выдающиеся).
Единственное забавное, что заметил http://seniors.com - мамба для тех, кому за сорок.
Касательно porn.com, у моей бывшей конторы был домен porn.ru, долго думали что-бы с ним такого сделать, в итоге тупо поставили редирект на один из более-менее тематических подразделов и плюнули.
etsy.com - идея- супер, очень жаль, что в России такого нет, а оттуда заморочно везти.
касательно dopplr'а, у меня летом была идея сделать нечто подобное, для своей тогдашней уже девушки- она ездит много и заколебали интересоваться в городе она или нет. Я даже практически запустил, но потом из этого начало вырастать кое-что побольше, я и вот этим кое-чем занимаюсь последние месяца полтора.
Если очень хочеться закэшировать 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-->
Точнее это можно сделать через префильтр, но я уже писал, что приведенное решение- скорее препроцессор шаблонов, так что ничто не мешает использовать его как префильтр смарти. Я во-всяком случае так и собираюсь делать, как только разберусь как перегрузить вывод смарти.
Это хорошо, что они переопределяются, плохо то что они одинаковые для инструкций вывода и управления, e.c. если мы хотим завернуть циклы и условия в HTML комментарии для лучшей "просматриваемости" шаблона, то нам придеться завернуть и переменные, что во-первых увеличит энтропию вселенной, так как будет больше кода, а во-вторых мы при предпросмотре не увидим куда какая переменная вставляется.
У Zend'а есть и свой шаблонизатор, идеологически больше всего напоминающий Blitz- вертим данными из контроллера.
Я такой писал года 3 назад, для интранет решений вполне хватало.
Правда договариваться долго и муторно.
Хотя все зависит от ситуации.
1. выделяем первые первые три бита маски под виртуальные группы: все, зарегистрированные, администрация
2. определяем нулевого (id=0) пользователя с отношениями для всех зарегистрированных пользователей (куча фейковых записей- бяка). Т.е.:
user_id ref_id mask
0 * 110...
Если запись "публичная" или "только для зарег" или "только администрация" то access соотв. буду 1,2 или 4, а us_id в records 0 (т.е. поле работает только для связи, идентификатор "владельца" будет дублироваться в другом поля.
Получаем выборку без UNION.
P.S. я не тестировал.
Просто основной целью было получить выборку объектов с проверкой прав доступа на уровне выборки из базы.
Если надо вывести, например, постранично френдленту, то получается что надо выбрать n объектов, проверить права на чтение, выкинуть запрещенные и довыбрать еще, при этом постраничный вывод становиться очень нетривиальным так как мы не можем получить количество записей, а ссылки вида ←→ вычисляются динамически.
1. Свободный график- это, конечно, хорошо, но проблем в том, что нет четко обозначенного конца работы, когда можно расслабиться, получается кривой рабочий день, и каждый раз когда делаешь перерыв, ты вроде как сам у себя время крадешь.
2. Делаешь кучу левой работы, галочку передвинуть или еще что-то, для этого приходиться разбираться в чужом html, что не всегда тривиально, в результате убиваешь несколько часов на то, чтобы найти куда у тебя стрелочка делась.
3. Как уже сказали комментаторы выше, серьезных проектов гораздо меньше, и кроме того если, работая в нормальной конторе, ты можешь предложить сделать какую-либо интересную фишку, и, вполне вероятно, что ты ее будешь делать, то на фрилансе придеться либо делать ее бесплатно, либо муторно согласовывать ее стоимость.
4. По деньгам, честно говоря, за три-четыре месяца, ничего не понятно, кроме того активно я заказы не искал, так как параллельно занимаюсь еще проектом для себя "на перспективу".
Хотя, на самом деле, от фриланса отказаться было довольно сложно, сделал это так как устроился в контору, в которой есть возможность значительно повысить скиллы.
Кэшировать html- хлопотно, так как он может различаться от пользователя к пользователю, кроме того у меня одни и те-же данные могут отдаваться в html и xml и в json- а узкое место именно доступ к бд.
Актуальность кэша- либо по времени жизни, либо через принудительное разрушение при обновлении (http://wiki.toukmanov.ru/dbSelect - тут подробнее, если интересно)
На каких-нибудь очень нагруженных страницах- вешаю тупой кэш html, отдаваемого модулем.
Чем-то напоминает.
Мне вот, например, надо было прикрепить к каждой ссылке картинку, по клику на которую вываливалась контекстная менюшка.
Единственное забавное, что заметил http://seniors.com - мамба для тех, кому за сорок.
Касательно porn.com, у моей бывшей конторы был домен porn.ru, долго думали что-бы с ним такого сделать, в итоге тупо поставили редирект на один из более-менее тематических подразделов и плюнули.
http://toukmanov.ru/imgs/stol.jpg
Рабочее место оборудовано котом.
касательно dopplr'а, у меня летом была идея сделать нечто подобное, для своей тогдашней уже девушки- она ездит много и заколебали интересоваться в городе она или нет. Я даже практически запустил, но потом из этого начало вырастать кое-что побольше, я и вот этим кое-чем занимаюсь последние месяца полтора.