О ходе разработки. BORS-флуд.

И снова — АвиаПорт. Для главной страницы готовится новый модуль с последними обновлениями раздела «Персоны». Просто 9 фотографий из последних изменившихся анкет, 3x3. Но, блин, загвоздка. Исходная задача — квадратные куски изображения. Но если резать тупо по середине, вписывая фото в квадрат, начинают резаться головы:

Плюс масштаб фотографий выходит совершенно разный.

Сперва реализовал вариант с прямоугольными, вытянутыми по вертикали превьюшками. Получилось лучше (портреты же обычно вертикальны), но всё равно — фигово.

А потом внезапно наткнулся на PHP-библиотеку PHP Face Detection. Поставил — и, о чудо, она реально вполне успешно (хотя в обзорах пишут, что не всегда) определяет положение лица. Дальше — дело техники. Обрезаем кусок вокруг него — и готово:

Не безупречно, но уже вполне терпимо для автомата. К тому же, я специально выбрал сложный случай, реально оно обычно получше:

Конечно, это далеко не OpenCV, можно прикрутить и последний, но это куда сложнее и возни больше. А тут — раз, и готово

Тестирую тут hhvm под своим объектным мультиязыковым бенчмарком ( github.com ). И что интересно. Для fib(30) hhvm оказывается на полтора порядка быстрее, чем PHP5.5 (что-то ~1.4 сек против ~50..60 сек.) Но на тестовых fib(40) hhvm оказывается медленнее, чем PHP5.5. (~200 сек. vs 158 сек.)

// Транслировано с juick.com

Начал переходить на управление классами через Composer. Решил вынесли разметку LCML в отдельный проект. На нём же и отработать загрузку классов через Composer. Решил как белый человек начать использовать PSR-4. И... обломался. Composer для классов PSR-4 не хранит в себе списки классов. Поэтому без сканирования файловой системы список имеющихся классов не получить.

Придётся для классов разметки LCML использовать классический подход, без namespace.

Сегодня извратился и развернул фреймворк под Windows
— PHP в CLI уже стоял.
— Поставил Composer
— Поставил Mercurial, SVN, Git

Установил через composer b2-framework, попробовал запустить (на встроенном в PHP сервере) словил пару ошибок, исправил — страничка грузится

Не работает пока отдача статики (то ли я раньше не довёл до ума, то ли под Windows с разделителями путей косяки), поправлю позже. Прикольно, последние попытки запускать BORS под Windows у меня были лет 7 назад... Не раньше 2008-го, т.к. в DVCS-истории с момента перехода на Mercurial в логах про Windows ничего нет. А тогда дело застопорилось из-за того, что ломало заморачиваться с Denwer.

MyBB, всё же, классный движок. Сейчас начерно одел страницы форума для Форекс на Forexpf.Ru - Торговля на Forex. Курсы валют. Прогнозы валютного рынка. в дизайн сайта на одних плагинах/хуках, не пропатчив ни строчки кода Аналогично реализована особая обработка сообщений от робота.

Единственный серьёзный минус движка — отсутствие простого средства переноса сообщений из топика в топик. Можно вынести сообщения в новый топик и подклеить его к имеющемуся, но это извращение. Надо будет тоже соответствующий плагин попробовать написать

Наткнулся на концептуальную проблему. Но давно заметил, что в случае таких проблем удобно взять всё и расписать для читателей форума/блога. Даже если совета не дадут, часто в процесс расписывания и раскладывания по полочкам возникает решение Не раз бывало даже так, что написав страницу-другую текста я всё написанное стирал и шёл реализовывать внезапно всплывшее решение. Так и тут, в целом картина понятна, но расписать всё самому не помешает.

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

Ну, например. Я хочу делать шаблон страницы на Bootstrap. Никаких проблем, в рамках нынешнего использования шаблонизаторов делаетя на 1-2-3. Что и делалось не раз. Но, опаньки. Многие элементы фреймворка, которые сами генерируют HTML заточены на упрощённый мой оригинальный шаблон. Для Bootstrap нужен другой код. На первый раз вводим ряд проверок (if(config('use_bootstrap')) { .. } else { .. } ). Где-то просто используются разные субшаблоны модулей ( page.tpl,  page.bootstrap.tpl). А потом разработчики убивают саму концепцию унификации фреймворков и выпускают несовместимый Bootstrap3. Приехали.

После долгого ломания головы родилась сущность layout. Это некий набор кирпичиков-шаблонов, характерный для каждого базового шаблона с его CSS и идеологией. Т.е., например, нужно модулю вывести таблицу на стандартном шаблоне, он скармливает данные layout-генератору (скажем, класс, bors_layout_legacy), который возвращает нужный HTML. Нужно использовать bootstrap — указываем, что HTML генерирует уже bors_layout_bootstrap и всё хорошо.

Отвлекусь по пути. Ещё появляется проблема названий. Традиционно у меня template указывает на движок шаблонизатора. Smarty, там, Twig или чистый PHP. Но также template — это шаблон всей HTML-страницы. Пока последние были «внеклассовыми», проблем не было. Сейчас появилась проблема. Шаблон страницы на bootstrap — bors_templates_bootstrap. Шаблонизатор Smarty — bors_templates_smarty. И сущности разные. Наверное, надо переименовывать шаблонизаторы из templates в templaters Благо, они напрямую за пределами ядра мало где используются и исправить будет не сложно.

И вот, я подхожу к задаче генерации общего шаблона.

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

Поэтому логика такая:
— Мы указываем в классе представления, каким общим шаблоном должен он выводиться. Например, var $template_class = 'bors_templates_bootstrap3';
— Метод $this->content(); каждого представления загружает из объекта этого шаблона-класса его дефолтовый layout, которым потом и пользуются модули и шаблонизаторы тела страницы.

...

Ну, вот. Когда всё расписал, и самому стало понятно, в какую сторону копать надо. Но вопреки привычке уже стирать написанное не буду, пущай висит

А, вообще, с новым подходом сильно упрощается логика работы шаблонизаторов. Им больше не нужно искать шаблоны по десятку разных критериев. Один класс — один шаблон в строго фиксированном месте. Нужно перекрыть шаблон своим? Просто делаем класс-наследник. Всё. И производительность в очередной раз подрастёт, так как меньше потребуется сканирования по каталогам...

«Bootstrap 3.0 and newer no longer supports multiple tier dropdowns for navigation bars»

Вот как после этого верить людям? :-/ Совсем, что ли, отказаться от BS?

// Транслировано с juick.com

А, может, пока не завяз в legacy, отойти от термина template и воспользоваться термином theme? Как в готовых движках меняют темы страниц, так и у меня шаблоны рассматривать как темы?

Вчера попробовал прикрутить к своему фреймворку фреймворк Lumen (на базе Laravel 5). В основном — с целью попытки освоить миграции БД. Что удивительно, прикрутилось почти сразу, в несколько строк кода. Забавно, что функции config() и config_set() в обоих фреймворках оказались одного формата, так что мой, загруженный после, работает с ними без нареканий.

Минус у Lumen/Laravel 5 пока только в том, что миграции не работают «из коробки» с пакетами Composer. Повозился немного, разобрался с форматом команд у artisan, прикрутил генерацию заготовки под миграцию (package:make:migration). Загрузка миграции вручную, с указанием пути, работает. Надо придумать, как автоматизировать совсем. Удаление миграции из пакета работает «из коробки».

В общем, нужно теперь будет осваивать. И есть мысль переписать свою консольную утилитку bors на использование artisan. И, вообще, можно интегрироваться с Lumen. Похоже, это не составит труда. А в качестве бонуса — огромное коммьюнити с массой пакетов.

Нашёл, наконец, работающий вариант двухсторонней синхронизации git ←→ mercurial.

Походу, перескачу через версию PHP-5.4. В кои-то веки не приходится тащить всякое Legacy с кривохостингами, а совсем старое умирает с прекращением поддержки PHP-5.3, за который я долго держался в разработке. Ну и раз всё равно уходим от PHP-5.3, то не на PHP-5.4, а сразу на PHP-5.5 с его генераторами и сопрограммами. Больно вкусные фишки, чтобы не перескочить через версию...

В очередной раз потребовалось ядро движка без всей прочей обвязки. Наверное, надо вычистить bors-core, оставив только базовый функционал. А всё прочее перенести в b2-framework (bors-framework?). Также и bors-ext закрыть в пользу b*-framefork и раздельных репозиториев.

То, что в PHP7 зарезервировали Null, не позволяя использовать в именах классов — ещё пережить можно. Но вот за намерения зарезервировать в будущем Object — надо руки отрывать. Это, по-моему, самый сильный удар по моей обратной совместимости за всю историю PHP Хорошо ещё, что я ленивый, и на namespaces перехожу очень медленно, так что классы bors_object в B2\Object успел поменять только в не массовом коде. Пришлось делать рефакторинг на использование B2\Nil и B2\Obj.