Еще немного о ближайших планах по развитию движка

Мне пишут в личку и спрашивают о подробностях. Понимаю, люди хотят бОльшей определенности. Решил вот написать чуть больше о своих планах. Уж не знаю, прибавит это определенности или нет, но, возможно, кому-то это будет интересно.

Конфигурация движка

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

Манифест-файлы плагинов и шаблонов сейчас в XML-формате. Есть желание перенести их в JSON, но я еще не решил, будет ли это в ближайшей версии или позже.

Расширение функционала

Функционал движка расширяется с помощью плагинов. Основным механизмом расширения является «динамическое автонаследование» — механизм, который я придумал и обкатал еще на базе ЛС, и который позволяет задействовать принципы ООП по максимуму.

Второй механизм — хуки. Причем, в Alto CMS вызов хуков оптимизирован так, что обработка каждого хука вызывается только в том случае, если есть зарегистрированный обработчик. Обработчики хуков могут задаваться как в виде самостоятельных классов, так и прямо в коде. В новой версии планируется еще один способ задания хуков — в конфигурационных файлах.

И в новой версии будет добавлен еще один механизм: замещение классов. Например, при вызове модуля User, файл класса ModuleUser.php сначала будет проверяться в папке /protected/app/classes/modules/user/, потом в /protected/common/classes/modules/user/ Т.е. для того, чтобы расширить модуль User, достаточно будет положить соответствующий файл в нужную подпапку в папку приложения, причем класс из /protected/app/ может быть расширением класса из /protected/common/. Такой вариант задумал давно, но только в новой версии возможна его реализация, т.к. есть поддержка неймспейсов.

Шаблонизация и ассеты

В свое время шаблонизатор Smarty подвергался критике из-за своей медлительности. Но третья версия Smarty вполне себе шустрая и гибкая. Сказать по правде, мне больше нравится шаблонизатор Fenom, но менять один шаблонизатор в обозримом будущем я не собираюсь.

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

Шаблоны из коробки в обозримом будущем останутся на базе Bootstrap 3 (я пока не нашел убедительных доводов для перехода на четвертый бутстрап)

Ассеты — css- и js-файлы в новой версии могут группироваться и размещаться в разных местах генерируемого HTML-кода. Например, часть файлов можно разместить в тегах head, а другую часть — в сам низу страницы.

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

Роутинг

Роутинг в Альто не просто гибкий, а очень гибкий. И он настраивается на двух уровнях — в конфиге задаются настройки до класса контроллера (или экшена, если в терминологии ЛС). И второй уровень — это настройки в самом контроллере. В ветке 1.х.х роутинг внутри контроллеров хоть и переделывался несколько раз, но подходы оставались те, что пришли из ЛС. В ветке 2.х.х будет реализован современный подход — роутинг с поддержкой стандарта PSR-7, и планируется это делать на Aura.Router, но с несколько измененным синтаксисом. В принципе, очень уж жесткой привязки к Ауре нет, так что это можно реализовать с помощью любой другой подобной библиотеки.

Работа с базами данных и кеширование

Из коробки декларируется поддержка MySQL, PostgreSQL и MS SQL. Но это, скажем честно, декларации. Знаю, что есть проекты на Альто, использующие Постгресс, но чтоб нормально так завести, нужно иметь прямые руки и некоторый набор знаний. Есть очень серьезные намерения добиться действительно нормальной поддержки Постгресса прям из коробки, чтоб раз — и завел. Я даже этот сайт сам хочу перенести в будущем на Постгресс.

ORM — еще один мой головняк. У меня есть пара собственных реализаций ORM, которые работают в разных проектах, но каждая имеет свои недостатки. В то же время, я убедился, что 80% запросов можно писать на ORM, очень экономя время разработки, а остальные 20% можно делать на голом SQL. В ближайшей версии планирую расшить самые узкие места в мапперах, а вопрос о внедрении полноценной ORM-системы откладываю на потом.

Собственно, сам функционал

Alto CMS — это многопользовательский мультиблоговый движок с элементами соцсетей, и он таким, в общем-то, остается (хотя для меня это — очень удобный инструмент для разработки сайтов очень разной направленности). Каких-то новых супервозможностей в обозримом будущем не планируется, но в планах остаются фичи, которые давно хотелось сделать:
* Базовая поддержка мультиязычности
* Полный уход от легаси-кода при работе с изображениями
* Доп.поля ко всем сущностям
* Универсальные теги, которые можно цеплять не только к топикам, а вообще к любым сущностям
* Категории — есть наработки, но не решил, как лучше с ними поступить — то ли прям в движок, то ли отдельным плагином
* Ну и всякие плюшки по мелочам

Чот хотел кратенько совсем, а получилось довольно много букв