Albireo Framework

19-10-2020Время чтения ~ 7 мин.Albireo Framework / CMS 4188

Сделал новый php-фреймворк для лендингов и статичных сайтов. Также Albireo можно использовать для публикации примеров кода и вообще там, где нужно что-то быстренько накидать на HTML, CSS, JS или PHP. Фреймворк очень небольшой по объёму, но имеет хорошие возможности.

В какой-то мере Albireo Framework можно считать альтернативой Landing Page Framework, который я сделал несколько лет назад. Но LPF сейчас больше ориентирован на создание небольших сайтов, поскольку там есть админ-панель, авторизация, да и вообще он довольно неплохо «напичкан» по функционалу. Изначально он планировался как что-то простое, но постепенно я добавлял в него новые возможности для решения разных задач.

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

Albireo Framework я позиционирую как удобный инструмент для лендингов (куда ж без них), простых сайтов, документации, примеров кода для любого сайта и просто как учебный проект для начинающих php-программистов.

Кроме этого Albireo прекрасно работает как генератор статичных сайтов — это когда на выходе формируются html-файлы, которые можно загрузить на любой хостинг (например на github.io).

Компактный

Суммарный размер всех php-файлов — примерно 35кБ. И это при том, что я добавил комментарии почти для каждой строчки/блока кода.

То есть когда нужно загрузить сайт на сервер, можно делать это одним скопом, не задумываясь о том, что где-то отдельно ядро, где-то данные, а где-то настройки. Кинули — и не морочим голову. :-)

Настраиваемый

Настраивается каждый каталог, шаблоны вывода, записи и т.д. Если в LPF (да и в других фреймворках) существуют какие-то предопределённые имена файлов и их расположение, то здесь делай что хочешь. При этом, что тоже важно, «системных» настроек всего пара штук. Скажем нужно обязательно указать шаблон вывода, а 404-страница всегда будет в файле 404.php.

Почему так? Albireo Framework может служить стартовым проектом для чего-то большего. Когда вы будете развивать сайт на его основе, то возможно захотите поменять имена каталогов.

Современный

У меня, как ни крути, большой опыт создания самых разных сайтов. LPF раньше был площадкой на которой я обкатывал разные идеи, которые потом добавлял в MaxSite CMS. Часть идей из MaxSite CMS использовалась в LPF, то есть это постоянный обмен и развитие. Как-то я уже писал, что периодически работаю над своим php-фреймворком (для себя) по уровню это что-то вроде CodeIgniter 4. И здесь я также понимаю, что какие-то вещи можно сделать проще и удобней.

Albireo — это как раз компиляция всех этих идей, которые поднимают его на уровень современных требований. Из ключевых я бы отметил: роутинг, шаблонизация, хранилище данных, поддержка REST, «умный» кэш.

Роутинг «мечты»

Про роутинг я раньше здесь писал, отмечу лишь, что преобладают два подхода.

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

Второй подход использует упрощенную схему роутинга. Пример — LPF: каталог страницы совпадает с её URL. Нужно поменять URL, меняем имя каталога. В других фреймворках используется похожая схема, только это может быть имя файла.

В Albireo любая страница может иметь любой адрес. Вот вообще любой. Например есть файл страницы about.php. В нём мы можем указать, что эта страница будет доступна по адресу сайт/myabout:

slug: myabout

Или сайт/company/info/webmaster/about:

slug: company/info/webmaster/about

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

Признаться, эту идею я вынашиваю уже пару лет для MaxSite CMS. То есть чтобы можно было не завязываться на сегменты и паттерны URL, как это принято в CodeIgniter, а указывать slug произвольно. Однако это слишком сложная переделка, поэтому вряд ли она будет реализована в MaxSite CMS.

Если «жесткого» адреса страницы недостаточно, то можно использовать дополнительный ключ slug-pattern, где можно использовать регулярные выражения. Так как это принято в «больших» фреймворках.

REST

Отправка http-запросов — всегда головная боль. Поэтому роутинг должен учитывать не только адрес, но и http-метод отправки. В «больших» фреймворках для этого также нужно прописывать паттерны адресов, где указывать и метод.

При этом браузеры поддерживают только POST и GET, а значит, чтобы оправить например PUT, приходится использовать обычный POST, только внутри его поместить поле _method с именем метода. Это современный, фактически ставший стандартом, способ работы с REST.

Albireo Framework также это поддерживает. Например есть обычная страница с формой. Она отправляет обычный post-запрос на этот же адрес. Соответственно, обработчик этого запроса можно разместить в любом файле с тем же slug, только указать ещё и http-метод:

slug: form
method: post

Причем метод вообще без разницы какой использовать, можно придумать любое своё название. Аналогично работает и AJAX. Я не буду здесь приводить примеры, поскольку они есть в документации, просто отмечу, что более простой работы с REST вы не встретите ни в одном другом фреймворке. :-)

Хранилище данных

Вот тоже интересная тема. Любой сайт вынужден использовать глобальное хранение данных. Если перейти на уровень ООП, то это паттерн Реестр вкупе в Мультитоном или Синглтоном.

Но, если смотреть в корень задачи, то в PHP (язык больших возможностей) это всё реализуется на обычных static-переменных. В итоге это всего одна функция storage() и две обёртки над ней: getVal() и setVal() и никакого засорения глобальной области видимости. :-)

Шаблонизация

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

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

То есть вы сами решаете как будет устроен шаблон/шаблоны сайта.

«Умный» кэш

С кэшами я уже «собаку съел», поэтому сделал вариант с ИИ. :-) Шутка.

Обычно кэш имеет время жизни, скажем 15 минут. Через это время кэш устаревает и его нужно стоить заново. Но на деле может оказаться, что данные в кэше вполне себе валидные и время его жизни никак не связано с устареванием данных. Такой способ работы с кэшем используется тотально, то есть вообще везде — оценка по времени его жизни.

В Albireo кэш работает совсем по другому. Есть данные, а это конкретный каталог albireo-data. И кэш смотрит когда было последнее изменение в этом каталоге и если запрашиваемый файл кэша старее, то отмечает его невалидным.

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

Генератор статичных сайтов

Такая потребность у меня возникла недавно, когда я делал документацию к Berry CSS. Набросал небольшой php-скрипт и прикрутил его к Gulp для автоматического запуска. Я об этом раньше уже писал. Но это конечно откровенный «велосипед», поэтому в Albireo я решил добавить уже нормальный вариант.

Вначале я решил посмотреть как дела в мире и был, мягко говоря, удивлён. Набрёл на какой-то проект, который для генерации использует Node.js: то есть сама документация — это 50 кБ, а с ней 200 мБ несколько тысяч js-файлов. Другие проекты не лучше: помимо больших размеров ещё и 100500 ограничений: на формат файла, синтаксис, кто-то требует вообще в json/xml-файлах ковыряться. А проекты на PHP ничего кроме синтаксиса markdown не понимают и почему-то требуют изучения twig-шаблонизатора, как будто бы PHP не достаточно. В общем, жесть...

Поэтому всё делал по своему. Генератор запускается в консоли через отдельный php-файл static.php. Он подключает Albireo как обычно и дальше скрипт генератора проходится по всем страницам и создает html-файлы. Если есть желание, можно тот же Gulp прикрутить, чтобы он запускал генератор при любом изменении файлов.

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

На выходе каталог с файлами, который загружаются на рабочий сервер.