Общие концепции B2 (BORS©2)

В процессе работы с BORS со временем появились несколько концептуальных моментов. Их реализация несколько меняет логику работы, так что, вместе с назревшим рефакторингом, было решено сделать небольшой ребрендинг и задуматься о выходе фреймворка B2 (т.е. BORS© v2). Новый вариант будет максимально совместим со старым кодом, переход будет поэтапным, фактически, BORS будет понемногу переписываться в B2. Но в некоторых местах придётся идти на волевой отказ от совместимости. Ниже подробнее о некоторых важных отличиях, решённых и нерешённых вопросах.

В отдельных сообщениях для удобства пополнения

Цепочные операции

Это часто реально удобно и для многих разработчиков уже привычно. Зачатки цепочных операций использовались в BORS и раньше, в частности в последнем варианте формирования запросов. Напомню, классический вариант запроса массива объектов в BORS выглядит так:

1. $topic_posts = bors_find_all('forum_post', array(
2.     'topic_id' => $this->id(),
3.     'is_deleted' => false,
4.     'order' => '-create_time',
5. ));

Для того, чтобы не ломать совместимость, новый формат запроса оформлен отдельной библиотекой.

И этот же запрос в новом формате в старом BORS запишется так:

1. $topic_posts = bors_find('forum_post')
2.     ->eq('topic_id', $this->id())
3.     ->eq('is_deleted', false)
4.     ->order('-create_time')
5.     ->all();

(Основные методы см. в классе bors_core_find (кстати, как на BitBucket дать ссылку не на текущую версию файла, а на последнюю?))

Минус виден сразу — запись становится более громоздкой Но есть и плюсы:
— Быстрее и однозначнее осуществляется парсинг выражения
— Единый класс для возвращения как массивов, так и единичных элементов
— Гибкое управление процессом выборки (скажем, ...->debug()->...)
— Декомпозиция сложного парсера на набор простых функций
— Лёгкость расширения

и т.д.

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

Всё есть объект

Возьмём массив постингов выбранного топика из предыдущего сообщения. Как обычно строится работа с ним?

1. $topic_posts = bors_find_all(...);
2. if($topic_posts)
3.     foreach($topic_posts as $post)
4.         ...

Или в шаблонах, в том же Smarty:

1. {if $topic_posts}
2. {foreach $topic_posts as $post}
3.         ...
4. {/foreach}

Основная же идея нового подхода в том, что возвращаться будет не массив (или NULL в случае отсутствия и т.п.), а объект, содержащий итератор:
foreach(b2::find(...)->...->all() as $post)

По синтаксису не сказать, что больше упрощение или усложнение, но — унификация. Таким образом планируется использовать практически любые системные объекты. Вот практический пример. Вставка привязанного к объекту изображения. Пусть это будет картинка по умолчанию для того же топика форума. Как это делается в BORS1:

1. {if $this->image()}{$this->image()->thumbnail('200x150')->html_code()}{/if}

Потому что если у нас нет изображения, то ->image() возвращает NULL и попытка обратиться к методу вернёт ошибку.

Так вот, в B2 основная концепция — никакой метод не должен возвращать NULL. Только корректные для обработки значения. Так что можно сразу выкидывать условие:

1. {$this->image()->thumbnail('200x150')->html_code()}

Особенно это полезно при реально длинных цепочках. Например:

1. {if $this->cabinet()}
2.     {if $this->cabinet()->owner()}
3.         {if $this->cabinet()->owner()->logo()}
4.             {$this->cabinet()->owner()->logo()->thumbnail('128x96')->html_code()}
5.          {/if}
6.     {/if}
7. {/if}

Теперь же [будет] достаточно одной таблетки цепочки:

1. {$this->cabinet()->owner()->logo()->thumbnail('128x96')->html_code()}

Не важно, в какой момент возникнет пустой объект (cabinet/owner/logo) — важно, что любая операция от пустого объекта вернёт также пустой объект. И никаких исключений не возникнет.

Нужно проконтролировать, чтобы был обязательно не ноль? Легко добавить в цепочку контролирующий метод, в духе ...->assert()->..., который уже и выбросит исключение в случае ошибки.

К сожалению, усложняется прямая проверка на непустой статус объекта. Увы, записать в PHP:

1. if(empty($this->target())) ...

уже не получится. Жаль, что в PHP отсутствуют магические методы для empty(). Придётся писать как:

1. if($this->target()->is_empty()) ...

(и, увы, ...->empty() мы написать тоже не сможем — это недопустимое для метода имя).

Вот тут вылезает одна из серьёзных несовместимостей с BORS1. Потому что придётся реально переписывать массу if(empty($this->target())). Поэтому я продумываю вариант введения такой логики совершенно отдельным слоем и отдельным набором методов/объектов.

Работа с Composer

Ну, тут всё просто и понятно. Конечная цель — разворачивание готовой к использованию системы одной командой. В Composer будут:

balancer/b2-framework — основной каркас для работы. Фактически, загружалка остальных компонентов в пригодном к использованию виде и их связывание.

balancer/b2-core — основное ядро системы. Все эти цепные функции, поиск и т.п. Тут потребуется большая работа по рефакторингу. Потому что нынешний bors-core сам по себе включает как фреймворк в целом, так и массу кода, который нужен редко. И в старом варианте может выноситься в bors-ext, а в новом — в отдельные пакеты Composer'а. Сейчас, на время разработки, b2-core тянет с собой весь bors-core. И, в общем, это будет надолго. Но цель — в разделении и рефакторинге.

balancer/b2-* в ассортименте. Конкретные пакеты/библиотеки для решения конкретных задач. В идеале установка должна быть не ручной, а на базе интерактивного инсталлятора. Указываем, что нам надо — оно и ставится через Composer.

(название не придумано) — также в планах создание на базе b2-framework готовой к использованию CMS. Развернул, запустил — и готов сайт. Да ещё, может быть, с опциональным указанием необходимых при установке компонентов (блог, форум, новости, рассылки…) Но это пока весьма дальняя перспектива, лично мне не актуальная и полезная только в смысле раскрутки фреймворка.

Встроенный web-сервер в PHP-5.4

Мелочь, и реализовать не так, чтобы сложно (хотя подводные камни есть). Очень полезно для всех, кто захочет быстро пощупать фреймворк. Не потребуется ломать голову о привязке к полноценному Web-серверу. Просто запускаешь скрипт — и PHP-демон сам обрабатывает запросы. Можно открывать браузер и смотреть, что как работает.

Когда-то для этой цели служил сторонний проект Nanoserv, но в настоящее время, в связи с интеграцией Web-сервера в PHP, Nanoserv потерял смысл.