С 2007 года мы жили на trunk-версии. Доколе! Хватит!

hg clone https://limb3.googlecode.com/hg/#RC-prepare limb2010.1

Список изменений настолько велик, что проще описать, что мы умеем:

Ядро – пакет CORE

Подключение классов и поддержка отложенной загрузки кода, работа с пакетами (lmb_package_*), работа с переменными окружения (lmb_env_*), проверка входных параметров (lmb_assert_*), коллекции и единичные контейнеры.

IoC  -пакет TOOLKIT

Пакет TOOLKIT – есть реализация паттерна Dynamic Service Locator. Суть этого паттерна состоит в том, что есть некий легко доступный объект, который является общим местом для доступа ко всем популярным объектам (сервисам) и в том, что возможности этого объекта можно легко расширять. Основное отличие от большинства подобных решений в том, что инстанцирование описывается императивно.

DBAL (Data Base Abstraction Layer) – пакет DBAL

В данный момент поддерживаются: MySQL 4.1+, SQLite, Oracle (OCI8), PostgreSQL 8.2+, Linter

Архитектура пакета DBAL вполне стандартная:

• Driver Драйвер (Driver) – базовые классы для работы с базами данных, которые абстрагируют доступ к базе данных. При помощи них осуществляются операции выборки и изменения состояния базы данных (select, update, insert, delete и т.д.).
• Query  - группа классов, позволяющих тем или иным образом инкапсулировать SQL запросы.
• Criteria  - группа классов, позволяющих строить условия для SQL запросов.
• Dump  - группа классов, используемых для загрузки sql-дампов.

ORM (Object-Relation Mapping) – пакет ACTIVE_RECORD

Первоначальная идея пакета ACTIVE_RECORD взята из фреймворка Ruby-On-Rails. RoR в данном случае выступали в качестве функционального ориентира, но мы не копировали полностью его API и функционал, а реализовывали только то, что было необходимо в текущий момент.

Основные характеристики:

• автоматическое определение наименований и типов полей таблицы
• поддержка отношений один-к-одному, один-ко-многим и много-ко-многим
• поддержка ValueObjects
• поддержка наследования в рамках одной таблицы (Single Table Inheritance)
• поддержка “отложенной загрузки” (LazyLoading) для коллекций
• тесная интеграция с шаблонными системами WACT и MACRO
• “жадные” операции  - attach и join
• пользовательские коллекции

Шаблонизация – пакеты VIEW, WACT и MACRO

limb3 следует парадигме MVC, как средству логичного разбиения кода, на относительно независимые куски. Пакет VIEW представляет одноименный слой MVC, и представляет из себя абстракцию от конкретного механизма шаблонизации. В данный момент основным шаблонизатором в limb3 является MACRO, пришедший на смену WACT’у. Помимо них VIEW поддерживает Blitz, JSON и нативный PHP.

MACRO – это своего рода syntactic sugar для нативного РНР. Мы пошли не по пути хэлперов, а остались верны тегам и фильтрам. Кратко о нем:

• промежуточная компиляция в PHP-код
• две области видимости переменных: глобальная и локальная (на уровне шаблона)
• механизм фильтров
• шаблоны комбинируются через include (включение дочернего шаблона), wrap (включение в родительский шаблон) и template+apply (применение шаблона)
• поддерживается концепция слотов
• готовые теги для работы со списками, деревьями, пейджингом, формами и их полями, ссылками и интернационализацией
• готовые фильтры для различного форматирования строк, чисел, дат и специальных форматов
• расширяем через собственные теги и фильтры

Веб-приложение – пакет WEB_APP

Пакет WEB_APP позволяет стоить веб-приложения, применяя парадигму MVC (Model-View-Controller). Сам WEB_APP пакет предоставляет классы для реализации только Controller составляющей. Выбор средства для реализации модели и отображения все равно лежит на конечном разработчике приложения, хотя пакет реализован таким образом чтобы максимально упростить работу с приложениями, где в качестве модели будут выбраны “родные” Limb3 пакеты DBAL и ACTIVE_RECORD, а в качестве отображения – пакет VIEW.

Limb3-приложения строятся обычно на основе цепочки фильтров, которая запускается из файла index.php. Цепочка фильтров стоится из набора типовых фильтров пакета WEB_APP или из тех, которые сочтет нужными реализовать конечный разработчик приложения.

Тестирование – пакет TESTS_RUNNER

TESTS_RUNNER – пакет для организации и запуска SimpleTest тестов для приложений, которые содержат большие тестовые наборы. В поставку с пакетом входят классы, которые позволяют выполнять тесты в cli или web-режиме.

Данный пакет не содержит никаких зависимостей от других пакетов, входящих в Limb3, поэтому может использоваться полностью отдельно.

Прочие пакеты

Набор практически стандартен: ACL, деревья, кэширование, календарь, CLI-скрипты, админка, работа с конфигами, конвертация дат, интернационализация, обработка изображений, отправка почти и так далее. Полный список пакетов можно найти на соответствующей странице в документации.

Инкубатор

Некоторое время назад мы ввели концепцию инкубатора. В него помещаются все “молодые” пакеты, которые еще не прошли испытание боем, недокументированные пакеты или пакеты не покрытые тестами. В данный момент в нем находятся:

• CONSTRUCTOR – генератор моделей, контроллеров, шаблонов на основе схемы БД
• PROFILE – средство для профилирования кода, запросов к БД и кешам
• CRON – базовая функциональность для крон-задач, с ведением лога в БД и административной страничкой просмотра этого дела

Текущие проблемы

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

Помимо этого на версии RC проходят не все тесты, но это поправим до релиза.

Итого

Если вы матерый РНР-программист, и всякие ZF и Symfony вам жмут в плечах и не дают расправить крылья, то приходите к нам. Мы очень гибкие, честно-честно.

• Код: hg clone https://limb3.googlecode.com/hg/#RC-prepare limb2010.1
• Документация
• Чтобы въехать (быстрый старт)
• Форум поддержки
• Временный треккер

Из этой проблемы формируются две гадости: во-первых правила долго писать, во-вторых по ним искать сложно. Попробуем пойти нестандартным путем и решить проблему, сделав роли более селективными.

Стандартные способы борьбы

Для уменьшения количества правил, обычно применяют наследование ролей и ресурсов, а так же множественные роли на один инстанс объекта. В итоге имеем дерево, нелинейный алгоритм, и количество проходов по нему отличное от нуля

Обратная сторона – использование масок доступа. Проверка по маске это быстро, но маска не бесконечная. А как же “показывать только друзьям”?

В общем надо решать как-то иначе.

Как же?

Кто лучше всех знает кем для статьи является конкретный пользователь?

Правильно, сама статья.

На практике оказывается, что информация, которая необходима для определения роли конкретного объекта, в рамках конкретного субъекта, лежит либо в самом субъекте, либо “близко” к нему. Так пусть он и определяет, кто в данный момент перед ним.

В LIMB’е это выглядит так:

class Article implements lmbRolesResolverInterface, lmbResourceProviderInterface
{
  function getRoleFor(Member $member)
  {
    if($this->getOwnerId() === $member->getId())
      return 'owner';
    if($this->getCategory()->getModeratorId() === $member->getId())
      return 'moderator';
  }

  function getResource()
  {
    return 'article';
  }
}

class Member implements lmbRoleProviderInterface
{
  function getRole()
  {
    return 'member';
  }
}

//простой пользователь сайта
$this->acl->addRole('member');

//наш контенто-писака, жаждущий кармы
$this->acl->addRole('owner', 'member');

//модер, уныло бдящий за порядком на сайте
$this->acl->addRole('moderator', 'owner');

//а я статья. Просто статья
$this->acl->addResource('article');

//простой пользователь может статью комментировать
$this->acl->allow('member', 'article', 'comment');
//автор ее редактировать
$this->acl->allow('owner', 'article', 'edit');
// модератор акцептировать
$this->acl->allow('moderator', 'article', 'accept');

/* создадим по объектику на каждую роль */
$just_member = new Member();
$just_member->save();
$owner = new Member();
$owner->save();
$moderator = new Member();
$moderator->save();

$category = new ArticleCategory();
$category->setTitle('About LIMB');
$category->setModerator($moderator);
$category->save();

$article = new Article();
$article->setCategory($category);
$article->setOwnerId($owner->getId());
$article->save();

/* проверим нашу "магию" */
var_dump($this->acl->isAllowed($member, $article, 'comment')); //bool(true)
var_dump($this->acl->isAllowed($member, $article, 'edit')); //bool(false)
var_dump($this->acl->isAllowed($member, $article, 'approve')); //bool(false)

var_dump($this->acl->isAllowed($owner, $article, 'comment')); //bool(true)
var_dump($this->acl->isAllowed($owner, $article, 'edit')); //bool(true)
var_dump($this->acl->isAllowed($owner, $article, 'approve')); //bool(false)

var_dump($this->acl->isAllowed($moderator, $article, 'comment')); //bool(true)
var_dump($this->acl->isAllowed($moderator, $article, 'edit')); //bool(false)
var_dump($this->acl->isAllowed($moderator, $article, 'accept')); //bool(true)

Данный подход впервые пришлось использовать при создании acl, для фреймворка Adept, а теперь подобная штука есть и в LIMB’е.

• сервера или нескольких серверов
• настроек сторонних приложений (http-сервера, СУБД, прочие хранилища данных и утилиты)
• нашей схемы размещения файлов (фото, видео, и прочий хлам контент)
• наших кэшей
• нашей структуры БД
• нашего кода
• бессоных ночей

Начнем с конца, пропустив бессоные ночи.

Обычно все начинают с одного и того же…

Коммунизм

Один сервер, одна база, один код. Правим по очереди или по алфавиту. Правки то и дело сопровождаются криками «Не трогайте пока User.php. Мне надо выборки поправить». Версионность кода поддерживается ежедневным архивированием папочки с кодом и дампом БД.

И надоело им материться, и явился им SVN (CVS, Git, Bazaar, нужное подчеркнуть). И поняли они, что это хорошо…

База на то и база, чтобы одна была

Стало лучше, но все равно то и дело слышаться возгласы «Ёп! Кто поле is_hidden у статьи убрал? Оно же во всех выборках! Давай коммить (новые выборки) быстрей!».

Призадумались ребята. Подумали, поспали, еще подумали. И поняли, что схему БД надо «привязывать» к коду, который с ней работает. Погуглили, и нашли:

• кучу утилит, которые умеют делать «diff» между двумя базами
• для ROR на Ruby – миграции на SQL DDL
• для Django на Python – DbMigration
• а для РНР — всю туже кучу утилит типа mysql diff, ну еще и Doctrine Migration для ORM Doctrine.

А отдельные храбрецы, разрабатывающие на LIMB‘е используют вот эту радость. Радость представляет из себя набор консольных утилит для автоматического создания, тестирования и применения миграций, а так же для создания дампов БД. Подробности можно прочитать на нашем форуме.
Все вроде бы хорошо, но вот беда — на продакшене кэши решили хранить в memcached, а на машинах разработчиков толи памяти мало, толи им на содержимое кэша часто смотреть приходится.

Делим cash, то есть cache

Что у нас есть такое куда смотреть легко, и где место не жалко. Эврика! Файлы на диске. Теперь дело за малым — нужна библиотечка, которая позволит простым изменением настройки переключаться между разными хранилищами.

ИМХО, каждый, уважающий себя, фреймворк должен иметь такую штуку. Хотя бы для того, чтобы мерятся с другими. У Zend Framework есть Zend_Cache. В LIMB таких штук целых две. Пакет сache — нормально работает и вполне стабилен (по API), и второй писал я, со всеми вытекающими. Пакет cache2:

• 6 хранилищ: память скрипта, APC, memcached, БД, файлы, сессия, фейк для тестов, (и еще, как минимум, добавится кэш в РНР-файл)
• хранилища будут иметь абсолютно одинаковый интерфейс и потокобезопасность:
  • add
  • get
  • set
  • delete
  • flush
  • increment/decrement
  • safeIncrement/safeDecrement
  • lock/unlock
• логгер, позволяющий отслеживать операции с кэшом
• утилитка для проведения микротестов
• полустабильное состояние

Вся информация о хранилище задается с помощью DSN. Например:

file:///tmp/cache //кэш на файлах
apc:///?prefix=foo //кэш в APC, ключи префиксуются строкой foo.

Ну совсем все радостно, но файлы на продакшене на отдельном сервере лежат, а у разработчиков локально надо. Или настройкой sphinx занимается только один человек, и поднимать его у остальных — бессмысленно.

Абстракция. Как много в этом слове

Как известно любая проблема, кроме одной, решается введением абстракции. Решим и нашу.

Для начала разделим каждый наш файл конфигурации на две части: общую и специфичную для конкретной машины. У нас это, например, avatar.conf.php и avatar.conf.override.php. Специфичные штуки игнорируем в нашей системе контроля версий. Общие кладем рядом с кодом. Желательно, чтобы в файле с общими настройками задавались настройки для продакшена. Тогда вы во-первых их(настройки продакшена) не потеряете, а во-вторых проще будет продакшен обновлять.

Разница при работе с медиа-файлами обычно сводится к двум задачам:

• куда-то положить
• откуда-то запросить

Для указания размещения файлов мы, используем URL и обычную функцию copy(). Например на продакшене

'scp://storage_user@storage_host1/'
.'?rsa_pub='.urlencode('/home/php-fpm/.ssh/id_rsa.pub')
.'&rsa;=' .urlencode('/home/php-fpm/.ssh/id_rsa').'/media'

, а на машине разработчика просто

'/www/somesite/www/media/'

Ну а с тем откуда запрашивать еще проще. Для продакшена 'img-1.somesite.ru/media/', а у разработчика somesite.pupkin.local/media/'. Это базовые пути и URL’ы для медиа-файлов. Остальное определяется, исходя из id файла.

Со Sphinx’ом поступим схожим образом. Добавим в конфигурационный файл директиву fake_search, которая будет определять тип поискового сервиса. Используя фабричный метод, наподобие такого:

static function createSearchService($config)
{
  if(!isset($config['fake_search']) || !$config['fake_search'])
    return SphinxClient();
  else
    return FakeSphinxClient();
}

, т.к. SphinxClient и FakeSphinxClient реализуют общий интерфейс, то для остальной программы такая замена пройдет незаметно. FakeSphinxClient будет просто отдавать первые подходящие объекты, а следовательно верстальщик сможет застилить страницу с результатами поиска, не занимаясь такими «магическими» штуками, как установка Sphinx.

Разработчики рады, и поют песни, восхваляющие абстракции. Осталась одна маленькая проблемка — разница в версиях ПО третих сторон, и их настройках.

Может хватит, а?

Вот на этом шаге мы остановились и находимся в данный момент. Следующий этап эволюции это работа в среде, максимально приближенной к «боевой». Т.е. работа на общем сервере, где с помощью виртуализации поддерживается среда, в которой нам придется работать на продакшене. У каждого свой код, своя база(и не одна), в общей СУБД, свои хосты. Все межсерверные взаимодействия отлаживаются еще на этапе разработки. И проблем с разными версиями ПО не возникает.

Коммит.

И пусть весь мир подождёт

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

Честные блокировки на генерацию

Решение в лоб. Первый пришедший лочит кэш на генерацию, и отправляется генерировать кэш. Остальные, увидев лок, понимают, что не успели, чешут репы и думают, что делать. Как именно делать лок зависит только от вашей фантазии и имеющихся средств. Это может быть, что угодно:

Лок файловой системы

есть косяки, но иногда работает . Подробности в описании функции flock().

Мьютекс в хранилище

Если мы используем memcache и генерируемый кэш имеет ключ «popular_articles», тогда наличие данных с ключем «popular_articles_lock», говорит о том, что наш кэш уже кто-то генерирует. Тоже самое справедливо и для других хранилищ.

IPC семафоры

Настоящие пацанские семафоры Ни разу не использовал — руки не доходят.

Плюсы локов в том, что клиент сам решает, что делать в ситуации, когда ему нужны данные, а их кто-то генерирует. Например, если есть старые данные, то мы можем их отдать, а если данных нет, то либо подождать, либо честно вывести пользователю, что данных нет. На самом деле висящие в течении секунды пользователи совсем не есть гуд, но иногда можно допустить и такое. Так же не стоит забывать, что при генерации может возникнуть ошибка, и в этом случае лок может остаться висеть(в случае memcache можно ставить ttl на лок).

Организация «окна» для генерации

Способ был подсмотрен в исходниках какого-то фреймворка Суть его в том, что ttl поддерживается не самим хранилищем, а клиентом, в виде отдельного ключа, и при истечение данные не удаляются. Т.е. приходит первый запрос, видит что ttl истек, и начинает генерировать новое значение. Чтобы остальные запросы подумали, что все нормально, он продлевает ttl существующего кэша на какую-то заранее определённую величину. Если писатель умирает, то кэш быстро снова протухнет и кто-нибудь подхватит знамя генерации с трупа павшего товарища. Если же все нормально, то будет записан новое значение кэша и установлен новый ttl. Основным минусом такого подхода является то, что ttl нельзя хранить средствами самого кэш-storage, т.к. во всех самых известных хранилищах невозможно получить значение ttl и сами данные с истекшим ttl.

Я хочу вас всех, я хочу вас сразу!

Случай у нас тяжёлый, и пользователю будет скучно коротать 20 секунд рисуя матом надписи на пыльном столе. Я знаю про кого будут эти надписи. Главное откровение: чтобы избавиться от последствий многопоточности надо свести ее к одному потоку. Просто и со вкусом. Убираем всю генерацию кэша в оффлайн. ttl-ем в данном случае будет время перезапуска генерирующих кэш скриптов. Помимо быстрого ответа пользователю тут есть еще один плюс — наборы кэшей часто генерировать быстрее, чем каждый из них по отдельности, ибо можно хранить какие-то промежуточные данные. UPD: Вот ещё статья по теме.

Зачем?

Хочется убить двух зайцев: избавиться от запросов за редко изменяемыми данными, и их отрисовки. Вообще это смахивает на попытку минимальным количеством движений сделать глобальное счастье. Можно потом перед другими фрэймворками меряться, ага.

На самом деле задача избавиться от отрисовки куска страницы вообще какая-то странная, если мы используем быстрый шаблонизатор. Application-сервера, при нормальной арихитектуре, масштабируются легко и непринужденно, а APC, сам закэширует скомпилированный шаблон, если он компилируется в РНР-код, как это сделано в Smarty, Macro и многих других.

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

Откуда данные, и как заставить протухнуть кэш.

Данные в шаблоне могут получаться двумя способами. Первый и традиционный это push-подход, когда контроллер заполняет какой-то data-transfer-object, или в сам шаблон. Такой подход используется чаще всего, ибо это “тру MVC”!

Второй подход – pull. При pull подходе в шаблоне расставляются инструкции по получению данных, в обход контроллера, напрямую от моделей, сервисов и прочих провайдеров данных. Этот способ позволяет избавиться от повторяющихся set’ов в контроллере, но не позволяет ограничить, из контроллера, их получение, и усложняет поддержку шаблонов, ибо иногда трудно понять откуда получены данные.

Теперь об определении развалидации кэша. Тут тоже два основных подхода. Первый – ttl(time-to-live – время жизни). Мы определяем, что список новостей, например, валиден в течении 15 минут. Основной плюс – мы уверены, что за данными скрипт будет обращаться не чаще чем раз в 15 минут, и зная частоту обращений можем точно расчитать эффективность такого кеша. Второй плюс – простота реализации. Главный же минус в том, что наш список на самом деле может измениться через секунду после построения кэша, а пользователь увидит изменения только через 15 минут.

Второй вариант сброса кэша – по действию. Например, тот контроллер(экшн), который отвечает за публикацию новостей, сам убивает кеш, и формирует новый (тут тоже много разных камней, типа lost updates, и прочих порождений многопоточности, но все они решаемы). Плюс – кэш всегда валиден. Первый минус это сложность реализации (нам нужно добавлять код для работы с кэшем во все места, где идет работа с данными кэша – публикация новостей, их удаление, и т.д.). Второй минус в том, что эффективность такого кэша сильно зависит от частоты изменения данных.

А теперь тоже самое, но в свете кэширования частей страницы.

Push me. And then just touch me…

Кэшировать части страницы, при push-данных хуже, чем кэшировать эти самые данные. Почему? Потому что мы “загадим” кодом работы с кэшем и шаблон, и контроллер, а из плюсов только экономия на отрисовке.

Pull-данные и развалидация по действию

Что мы получаем? Логика работы с кешем в шаблоне и тех контроллерах, которые отвечают за действия. Опять не тру, и лучше опять кэшировать данные, через какой-нибудь LastNewsService.

Pull-данные и ttl

Вот то ради чего собственно и делаются теги cache, блоки django, компоненты и т.д. Вся логика только в шаблоне (или настройках компонента). Красотища!

Вывод:

Кэширование части HTML имеет смысл только для pull данных с устареванием по времени. Во всех остальных случаях его плюсы, по сравнению с кэшированием данных, сводятся к экономии работы шаблонизатора.

То о чем так долго говорили большевики…

Кратенько:

• пространства имен
• mysqlnd
• позднее статическое связывание
• динамические вызовы статических методов
• Прочие изменения

А теперь подробно…

Пространства имен

/* Серое и унылое настоящее */
class MyAclSimpleRole {}
$a = new MyAclSimpleRole;

/* или (Zend FW) */
class My_Acl_Simple_Role {}
$a = new My_Acl_Simple_Role;

/* А теперь так */
namespace My::Acl::Simple;
class Role {}

/* По прежнему можем использовать полное имя */
$a = new My::Acl::Simple::Role;

/* А если use добавить... */
use My;
$a = new Acl::Simple::Role;

use My::Acl;
$a = new Simple::Role;

use My::Acl::Simple;
$a = new Role;

/* А если alias добавить, то вообще красота */
use My::Acl::Simple as defaultAcl;
$a = new defaultAcl::Role;

use My as default;
$a = new default::Acl::Role;

class Foo {
  public static function whoIsItDrinkins() {
      return __CLASS__;
  }
}

class Bar extends Foo {}

echo Bar::whoIsItDrinkins(); //Foo

class Foo {
  public static function whoIsItDrinkins() {
      return get_called_class();
  }
}

class Bar extends Foo {}

echo Bar::whoIsItDrinkins(); //та-да!

class FooFactory {
  static function call() {
    echo 'Простите все операторы сейчас заняты';
  }
  static function __callStatic( $methodname, $args ) {
    echo '

Добрый день! Вы только вызвали статический метод ' . $methodname . '

';
    echo '

С параметрами:

';
    echo '

' . print_r( $args, true ) . '

$posted_articles = Articles::findByIsPosted(true);

$new_members = Member::findByRegistrationDateLessWhat($today);

$method = 'callAnotherTime';
FooFactory :: $method('Я вас каждый день вызывать буду!');