Що ми знаємо про MODX 3 на даний момент?

Кілька тижнів тому провідний архітектор Джейсон Ковард (Jason Coward, «opengeek») поділився своїм баченням про майбутнє MODX на майданчику Medium. Ґрунтуючись на цій інформації, а також на інших обговореннях в мережі, що ми знаємо про MODX 3? Який його статус, і коли ми можемо побачити щось наживо?

Чесно кажучи, у нас поки немає точних відповідей. Є тільки деякі частини інформації, які ми можемо скласти разом. Оскільки 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.