Несколько недель назад ведущий архитектор Джейсон Ковард (Jason Coward, «opengeek») поделился своим видением о будущем MODX на площадке Medium. Основываясь на этой информации, а также на других обсуждениях в сети, что мы знаем о MODX 3? Каков его статус, и когда мы можем увидеть что-то вживую?
Честно говоря, у нас пока нет точных ответов. Есть только некоторые части информации, которые мы можем сложить вместе. Поскольку MODX 3 еще попросту не создан, существует множество допущений и «продвинутых» предположений. MODX 3 – это долгосрочный проект, который только запускается.
Множество людей отлично пользуются текущей версией MODX. Система позволяет дизайнерам и фронтенд разработчикам создавать полностью уникальные сайты с минимальными усилиями и изменениями ядра в отличие от некоторых конкурентов. Даже в текущей версии разработка сайтов будет простым и полностью осуществимым делом в течение многих последующих лет. Очень мощный язык шаблонов и элементов, дополнительные поля (TV) и расширения – все это уже готово для использования в будущем.
Возможно, наибольшая причина, почему нам нужен MODX 3, – это просто число. С целью очищения унаследованного кода и предоставления разработчикам улучшенных средств, соответствующих стандартам отрасли, системе MODX будут нужны критические изменения. А поскольку MODX следует принципам семантического версионирования, это означает, что мажорная версия должна увеличиться в момент реализации критических изменений. Для MODX Revolution установлена версия №2, значит, нам будет нужна версия №3.
Так почему же нам нужны критические изменения, если текущая версия MODX все еще очень актуальна? Я бы сказал, это нужно для того, чтобы MODX следовал в потоке изменений мира PHP. Сообщество PHP становится более профессиональным и стандартизированным (в частности, благодаря The Framework Interoperability Group – группе концепции совместимости и инициативам вроде PHP: The Right Way – PHP: правильный путь) с впечатляющей скоростью в последние несколько лет. Включаясь в это движение, код ядра MODX может стать намного более классным (читай: стабильным, тестируемым и, возможно, меньше по объему). И наоборот, MODX стал бы намного более привлекательной платформой для других разработчиков на PHP.
В мире разработки критические изменения происходят постоянно. С исключительным прыжком от Evo к Revo MODX стал на самом деле стабильнее и продолжал развиваться в прошедшие года, но с определенных точек зрения критический релиз должен произойти, чтобы превзойти все то, что позволяет существующий код.
Во многих случаях MODX был разработан при использовании концепции «неприятия чужой разработки» (тенденция сознательно или инстинктивно игнорировать все инновации, которые происходят за пределами организации – прим. переводчика), являющейся не лучшим паттерном проектирования. В основном это означает, что если ранее каждая часть кода была разработана внутри сообщества MODX, то в будущем могут быть использованы более стандартизированные библиотеки, которые разработаны внешними сообществами. Благодаря Composer и Packagist, такое изменение произошло внутри сообщества PHP в последние годы, что позволило максимально просто использовать код внешних разработчиков, а также ускорило рост отдельных библиотек, выполняющих исключительно хорошо одну, четко определенную задачу.
Подключая такие внешние библиотеки сторонних разработчиков, становится возможным разрабатывать надежные приложения быстрее и лучше, используя преимущества полностью протестированного кода отдельных модулей (юнит тесты). Поскольку сейчас в MODX нет никаких полезных юнит тестов (хотя все же существует некоторое движение), это имеет большое значение с точки зрения архитектуры и качества кода.
Приведу некоторые примеры модулей, которые были разработаны внутри команды MODX ранее до использования внешних библиотек:
Это только самые первые вещи, которые приходят на ум, когда мы говорим о повторном использовании готового внешнего кода.
Во второй части серии своих статей «Поддерживая MODX в актуальном состоянии», Джейсон отметил фреймворк Slim (версия 3) как наиболее вероятного кандидата для использования в ядре MODX. Это не прошло незамеченным – многие люди начали рассматривать Slim, выясняя, что это такое и как он работает.
Вот что нам нужно знать о Slim:
Предположительно, Slim займет место текущих обработчиков запросов и ответов в MODX. Учитывая возможность добавления middleware-кода, это привело бы к крайне гибкой и мощной системе.
Если вы спросите случайную группу MODX-разработчиков об их самой нелюбимой части системы, скорее всего, это будет ExtJS (или в более общей форме – «Менеджер»). На данный момент пока не существует определенного направления для Менеджера, о котором я бы знал, но привязка к ExtJS 3.4 – это явно не то, что должно произойти. ExtJS 3 очень устарел, он недостаточно быстрый и не обеспечивает должной поддержки мобильных устройств. Более того, ExtJS 3.4 больше не обновляется, поскольку ExtJS 6 уже доступен в раннем доступе.
Так что хотя мы пока не знаем, как будет выглядеть Менеджер или на чем он будет построен, мы можем быть вполне уверены, что это не будет ExtJS 3.
Но что же мы знаем?
Учитывая выбор Джейсона в виде Slim как библиотеки ядра, его работы над неким проектом Tacit («высокопроизводительным RESTful фреймворком», основанном на Slim), а также некоторые обсуждения в различных IRC каналах и Slack, наиболее похоже, что следующий Менеджер получит RESTful API в качестве своей основы. Текущий Менеджер также обладает API, но его структура не полностью стандартизирована, а местами направлена именно на то, что от него ожидает ExtJS. Определенно, это не RESTful.
При переходе на RESTful API в качестве основной службы бекенд и интерфейс будут дополнительно разделены с точки зрения кода. Это должно позволить проще разрабатывать по-настоящему уникальные Менеджеры, причем делать эти две части платформы независимо друг от друга. Дизайнеры могли бы сфокусироваться на разработке интерфейса Менеджера третьей версии, а разработчики тем временем работали бы над надежным API.
Прямо сейчас Джейсон работает над долгожданной третьей частью своей серии статей о будущем MODX. В этой части он поделится своим видением на тему устойчивости – в основном, взаимодействия с базой данных. Для архитектуры MODX это очень важное решение, поэтому Джейсон готовит несколько возможных вариантов перед публикацией результатов.
На данный момент основной фокус MODX – это версия 2.3 и приближающаяся версия 2.4. Выпуск MODX 3 обещает стать захватывающим и привлекательным, так что важно потратить некоторое время для выработки решений перед определением основ новой революции в MODX.
Честно говоря, у нас пока нет точных ответов. Есть только некоторые части информации, которые мы можем сложить вместе. Поскольку MODX 3 еще попросту не создан, существует множество допущений и «продвинутых» предположений. MODX 3 – это долгосрочный проект, который только запускается.
Почему нам все равно нужен MODX 3?
Множество людей отлично пользуются текущей версией MODX. Система позволяет дизайнерам и фронтенд разработчикам создавать полностью уникальные сайты с минимальными усилиями и изменениями ядра в отличие от некоторых конкурентов. Даже в текущей версии разработка сайтов будет простым и полностью осуществимым делом в течение многих последующих лет. Очень мощный язык шаблонов и элементов, дополнительные поля (TV) и расширения – все это уже готово для использования в будущем.
Возможно, наибольшая причина, почему нам нужен MODX 3, – это просто число. С целью очищения унаследованного кода и предоставления разработчикам улучшенных средств, соответствующих стандартам отрасли, системе MODX будут нужны критические изменения. А поскольку MODX следует принципам семантического версионирования, это означает, что мажорная версия должна увеличиться в момент реализации критических изменений. Для MODX Revolution установлена версия №2, значит, нам будет нужна версия №3.
Так почему же нам нужны критические изменения, если текущая версия MODX все еще очень актуальна? Я бы сказал, это нужно для того, чтобы MODX следовал в потоке изменений мира PHP. Сообщество PHP становится более профессиональным и стандартизированным (в частности, благодаря The Framework Interoperability Group – группе концепции совместимости и инициативам вроде PHP: The Right Way – PHP: правильный путь) с впечатляющей скоростью в последние несколько лет. Включаясь в это движение, код ядра MODX может стать намного более классным (читай: стабильным, тестируемым и, возможно, меньше по объему). И наоборот, MODX стал бы намного более привлекательной платформой для других разработчиков на PHP.
В мире разработки критические изменения происходят постоянно. С исключительным прыжком от Evo к Revo MODX стал на самом деле стабильнее и продолжал развиваться в прошедшие года, но с определенных точек зрения критический релиз должен произойти, чтобы превзойти все то, что позволяет существующий код.
Синдром «это придумали не мы»
Во многих случаях MODX был разработан при использовании концепции «неприятия чужой разработки» (тенденция сознательно или инстинктивно игнорировать все инновации, которые происходят за пределами организации – прим. переводчика), являющейся не лучшим паттерном проектирования. В основном это означает, что если ранее каждая часть кода была разработана внутри сообщества MODX, то в будущем могут быть использованы более стандартизированные библиотеки, которые разработаны внешними сообществами. Благодаря Composer и Packagist, такое изменение произошло внутри сообщества PHP в последние годы, что позволило максимально просто использовать код внешних разработчиков, а также ускорило рост отдельных библиотек, выполняющих исключительно хорошо одну, четко определенную задачу.
Подключая такие внешние библиотеки сторонних разработчиков, становится возможным разрабатывать надежные приложения быстрее и лучше, используя преимущества полностью протестированного кода отдельных модулей (юнит тесты). Поскольку сейчас в MODX нет никаких полезных юнит тестов (хотя все же существует некоторое движение), это имеет большое значение с точки зрения архитектуры и качества кода.
Приведу некоторые примеры модулей, которые были разработаны внутри команды MODX ранее до использования внешних библиотек:
- Журналирование. На данный момент существует удобный метод $modx->log(), однако при изменении данного метода в соответствии с поддержкой интерфейса PSR-3 разработчики смогут сбрасывать записи лога в различные системы журналирования, например, в такие, как Monolog. Система Monolog предоставляет огромное количество впечатляющих возможностей по управлению логами, и когда MODX начнет поддерживать PSR-3, можно будет поддерживать любые из них без изменения ядра MODX.
- Маршрутизация. Существуют библиотеки, которые могут делать довольно крутые штуки с трансформированием запроса в правильный ответ. Смотрите раздел о фреймворке Slim ниже.
- Система шаблонов. Честно говоря, мне действительно нравится язык шаблонов в Revolution, но, возможно, использование чего-то более «стандартного» наподобие Twig могло быть интересным улучшением. В любом случае это снизит кривую обучения для многих людей, поскольку Twig используется во многих других проектах.
Это только самые первые вещи, которые приходят на ум, когда мы говорим о повторном использовании готового внешнего кода.
Что такое Slim и зачем его использовать?
Во второй части серии своих статей «Поддерживая MODX в актуальном состоянии», Джейсон отметил фреймворк Slim (версия 3) как наиболее вероятного кандидата для использования в ядре MODX. Это не прошло незамеченным – многие люди начали рассматривать Slim, выясняя, что это такое и как он работает.
Вот что нам нужно знать о Slim:
- Slim – это маршрутизатор. Он трансформирует Запросы (например, GET /manager/resource/update) в Ответ (например, в форму для обновления ресурса).
- Slim поддерживает паттерн Middleware (промежуточное программное обеспечение). При использовании данного паттерна вы по существу получаете множество слоев, которые обрабатывают каждый отдельный запрос, а также ответы с возможностью менять их до того, как они достигнут следующего слоя. Техническое объяснение паттерна Middleware можно найти здесь. Паттерн Middleware – это очень эффективный путь для расширения поведения. Slim 3 фактически поддерживает стандарт PSR-7 (черновик) из PHP FIG в его реализации Middleware, что означает, что любой middleware-код с поддержкой паттерна PSR-7 может быть спокойно использован вместе с Slim 3.
- Slim 3 пока еще находится в разработке; иными словами, он еще не готов для работы в реальном производстве, но похоже, код Slim 3 становится стабильным.
Предположительно, Slim займет место текущих обработчиков запросов и ответов в MODX. Учитывая возможность добавления middleware-кода, это привело бы к крайне гибкой и мощной системе.
Что насчет Менеджера и ExtJS?
Если вы спросите случайную группу MODX-разработчиков об их самой нелюбимой части системы, скорее всего, это будет ExtJS (или в более общей форме – «Менеджер»). На данный момент пока не существует определенного направления для Менеджера, о котором я бы знал, но привязка к ExtJS 3.4 – это явно не то, что должно произойти. ExtJS 3 очень устарел, он недостаточно быстрый и не обеспечивает должной поддержки мобильных устройств. Более того, ExtJS 3.4 больше не обновляется, поскольку ExtJS 6 уже доступен в раннем доступе.
Так что хотя мы пока не знаем, как будет выглядеть Менеджер или на чем он будет построен, мы можем быть вполне уверены, что это не будет ExtJS 3.
Но что же мы знаем?
Учитывая выбор Джейсона в виде Slim как библиотеки ядра, его работы над неким проектом Tacit («высокопроизводительным RESTful фреймворком», основанном на Slim), а также некоторые обсуждения в различных IRC каналах и Slack, наиболее похоже, что следующий Менеджер получит RESTful API в качестве своей основы. Текущий Менеджер также обладает API, но его структура не полностью стандартизирована, а местами направлена именно на то, что от него ожидает ExtJS. Определенно, это не RESTful.
При переходе на RESTful API в качестве основной службы бекенд и интерфейс будут дополнительно разделены с точки зрения кода. Это должно позволить проще разрабатывать по-настоящему уникальные Менеджеры, причем делать эти две части платформы независимо друг от друга. Дизайнеры могли бы сфокусироваться на разработке интерфейса Менеджера третьей версии, а разработчики тем временем работали бы над надежным API.
Что дальше?
Прямо сейчас Джейсон работает над долгожданной третьей частью своей серии статей о будущем MODX. В этой части он поделится своим видением на тему устойчивости – в основном, взаимодействия с базой данных. Для архитектуры MODX это очень важное решение, поэтому Джейсон готовит несколько возможных вариантов перед публикацией результатов.
На данный момент основной фокус MODX – это версия 2.3 и приближающаяся версия 2.4. Выпуск MODX 3 обещает стать захватывающим и привлекательным, так что важно потратить некоторое время для выработки решений перед определением основ новой революции в MODX.
