Joomla! 4 и выше: архитектура и дизайн

В двух предыдущих статьях этого цикла мы обсудили целевую аудиторию для Joomla! 4 и выше, а также ее вид для конечного пользователя. В этой (третьей) части мы увидим ее перспективы для  разработчиков, а также определим вид архитектуры PHP-кода и задачи дизайна.

Доступность

Я говорил, что Joomla! требуется улучшение доступности. По всей видимости, это необходимо для Joomla! в государственном секторе многих стран. Это не моя область, поэтому я думаю, что для этого необходимы предложения от экспертов в данной сфере.

Современный CSS фреймверк

Joomla! 3 на годы застряла на Bootstrap 2. Но что еще хуже, это даже не Bootstrap 2, это собственная неудачная его версия. Может быть, это имело смысл в 2011 году, но в 2015 это все-равно, что пытаться использовать для общения сигнальные огни, когда все остальные используют текстовые сообщения. Нам нужен современный, актуальный CSS фреймворк.

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

По второму мнению – обзавестить парой для Joomla! было очень эффективно. Bootstrap - это замечательный фреймверк, и мы должны его придерживаться. Однако немаловажно всегда использовать последнюю версию, выпущенную не позднее 6 месяцев, чтобы соответствовать циклу разработки Joomla!. Мы НЕ должны бояться нарушить обратную совместимость при обновлении до последней версии Bootstrap. Я знаю, что был против этого четыре года назад, но я увидел, что сейчас мы глубоко застряли в нашем устаревшем CSS фреймверке.

JLayout - залог успеха

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

А) использования DOM-модели фреймверка

Б) доступности вспомогательных функций JavaScript

По сути, JLayout это HTML уровень абстракции (abstraction layer).

Что если бы мы могли использовать JLayout, чтобы подгружать код JavaScript абстракции? Я знаю, что некоторые JLayout шаблоны уже практически могут загружать свои скрипты, но только для решения задач ядра Joomla!. Если я - сторонний разработчик, который хочет динамически отображать кнопки или изменять цвет ярлыка на лету, хоть и на JavaScript, то мой единственный вариант сейчас - создать AJAX-вызовы, которые создадут новую HTML-страницу и заменят содержимое той страницы, которую пользователь просматривает в данный момент. Это неправильно и нецелесообразно по многим причинам!

Давайте развивать общую библиотеку JavaScript, проксирующую Bootstrap. Если разработчики решат использовать CSS фреймворк XYZ - они обязаны предоставить переопределение для этой общей библиотеки JavaScript. Это позволит сторонним разработчикам поддерживать разные шаблоны без ужасной грубой подгрузки Bootstrap с пространством имен (да, я сам занимался этим кошмаром...) или без изобретения своих собственных CSS-фреймворков, которые не выглядят "правильно" в сторонних шаблонах.

Смена вида шаблонов

Одним из новшеств на Joomla! 1.5 (вернемся назад в '06 год), было внедрение вида шаблонов, который отделил код, который создает материалы от кода, который их отображает. Это было здорово, но...  это было здорово девять лет назад. Вы давно смотрели на наши шаблоны? В них очень много PHP-кода. Фронт-энд разработчик должен иметь гораздо больше, чем поверхностное представление о PHP для стилизации.

Между тем в PHP-мире появился Laravel. И в нем ну совсем просто понять его Blade-шаблоны. И он сделал прорыв! Он невероятно мощный и, ко всему прочему, легкий для интерфейсного разработчика, ведь чтобы понять и настроить РНР, не надо вдаваться в конкретику. И да, Larevel может быть портирован на Joomla!, я это уже делал.

Синтаксис Blade позволяет нам упростить жизнь разработчиков еще больше, добавив поддержку для конструкций типа @jlayout('com_example.foo.bar', $this->items, $somethingElse). Сравните это с типичным JLayout вызовом кода ядра и вы увидите, куда это идет. Как говорил Дарт Сидиус: ВЛАСТЬ! АБСОЛЮТНАЯ ВЛАСТЬ!

PHP 5.4 и выше

PHP 5.3 мертв с августа 2014. PHP 5.4 будет мертв в августе 2015 года, но, по крайней мере, мы знаем, что все общие хосты поддерживают его – за исключением тех, которые не должны быть подключены к Интернету! – по крайней мере в качестве опции.

PHP 5.4 позволяет нам писать код компактнее и с меньшим дублированием, используя трейты. Это и есть практическая причина, стоящая за этим предложением. Мы могли бы избавиться от 15% наших ключевых компонентов кода и уменьшить количество ошибок, с которыми приходится иметь дело. Убиваем двух зайцев одним выстрелом.

Только MySQL (и совместимые варианты)

Я знаю, что это не устроит тех 10 человек, которые используют Joomla! с Microsoft SQL Server и PostgreSQL. Существует несколько практических причин для этого, а именно:

• Оптимизации запросов. Наши запросы не являются оптимальными и приводят к плохой производительности, особенно на больших сайтах. Если мы знаем, что ядром предполагается работа только с MySQL, мы можем использовать MySQL опыт администраторов баз данных сообщества Joomla! с долгосрочным предложением помочь, чтобы сделать Joomla! быстрее. Это станет отличным инициативным преимуществом и классным маркетинговым ходом.
• Снизить порог вхождения и ошибки в деплойменте. Если кто-то поставляет новую функцию с изменениями схемы, то он должен внести эти изменения в формат MySQL, PostgreSQL и MSSQL-сервера. Каждый в двух разных местах. Это ставит в тупик разработчиков, которые очень опытны в PHP и MySQL, но не могут себе позволить вновь и вновь учиться и тестировать СУБД PostgreSQL и MS SQL сервер. Но что еще хуже, изменения схемы PostgreSQL и MS SQL Server обычно объединяются непроверенными, и ошибки можно обнаружить только спустя долгое время после релиза.
• У нас нет людей, чтобы поддержать 3+ различных технологий сервера. Доказательством является то, что в PostgreSQL интеграция была сломана очень долгое время (минимум 1 год) и никто не заметил. Даже когда мы заметили, потребовалось несколько месяцев, чтобы исправить это. Я до сих пор понятия не имею, по как драйвер MS SQL сервера действительно работает.

Так что давайте прекратим поддержку дополнительных типов баз данных. Мы можем оставить для них драйверы в ядре (для Joomla! Framework?) для использования сторонними разработчиками и корпоративными пользователями. Ядро будет поддерживать работу только под управлением MySQL.

Что же касается самой MySQL, с тех пор как мы еще не можем повысить минимальное требование до MySQL 5.6, нам пока придется иметь кучу проблем с тем, что основными таблицами нужна поддержка полнотекстового поиска, привязанная к MyISAM (и отрубить голову каждому, кто предполагает преобразование их к InnoDB).

Избавиться от UCM 

UCM всегда был готовым только наполовину, и навсегда таким останется, так что давайте просто избавимся от него. Он не требуется для тегов и содержимого версий. Нам просто нужны таблицы с назначением тегов  и контента, а также одно дополнительное поле, обозначающее тип контента. Затем мы можем использовать что-то вроде используемых в Laravel отношений "morphable" , чтобы все это работало. Если вы почитаете Laravel документацию, то в любом случае, вы увидите, в конце концов, что использовать кейс morphable отношений – это отличный вариант.

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

Удалить большое количество расширений кода

Но согласно существующего плана. Сейчас мы проигрываем как минимум в одной вещи, а именно в рекламе для наших пользователей расширений, поддерживаемых ядром. Я думаю, что страница «Установить из Сети» («Install from Web») должна иметь две зоны: поддерживаемые ядром расширения и список наиболее популярных JED категорий. Это позволяет нам сказать пользователям, куда пойти, чтобы быстро добавить функции, которые они не нашли в ядре. Этот подход прекрасно работает для WordPress: страница «Добавить плагин» - это, по сути, автоматически сформированный список или список спонсируемых плагинов.

Пространства имен везде

Так как это основная версия, я верю, что мы можем окончательно разорвать обратную совместимость и создать полноценный код пространства имен. Это также позволит упростить наш код, так как это будет наконец-то возможность отделить фронтенд MVC класс от бэкненд MVC класса. Ранее это было просто не возможно, так как они оба носили одинаковое имя.

Кроме того мы можем полностью покончить с JLoader. Вместо этого, можно использовать PSR-4 от Joomla Composer -  автозагрузчик, который уже идет вместе с Joomla!. Это позволит избавиться от ошибок кодах сторонних разработчиков, вызванных перемещением классов ядра из libraries/joomla в libraries/cms, либо классов, не следующих текущей схеме автозагрузчика. 

Обратная Совместимость слоя, по крайней мере, для 4.х

Новая версия CMS бесполезна без расширений сторонних разработчиков. Это наша работа, как разработчиков, облегчить переход из кода, написанного для Joomla! 3 на Joomla! 4. Это может быть реализовано путем создания слоя совместимости, который добавляется к классам алиасов и бэкпортов устаревшего кода для наиболее часто используемых базовых интерфейсов API. Это позволит разработчикам продолжить свой путь в направлении совместимости Joomla! 4 без страха, что им придется все начинать с нуля.

А если бы мы задокументировали процесс преобразования для существующего кода, то, ко всему прочему, смогли бы получить отличные дивиденды. Если тот, кто читает это, сомневается в целесообразности такого плана, у меня есть страница, которая доказывает, что я не бросаюсь словами на ветер.

Улучшенная интеграция Composer

Необходимо переместить composer.json и composer.lock в папку libraries, а не в libraries/vendor. Это позволит добавлять требования без существенного вмешательства в ядро.

Это также позволит сторонним разработчикам добавлять требования для установки в Joomla Composer во время установки / обновления расширений. Нам нужно увидеть, что это возможно на общих узлах без CLI доступа  – как пример стоит посмотреть это Drupal 8 обсуждение. Это требует привязки к общему рефакторингу com_installer. Однако изучение осуществимости задачи должно сосредоточиться на вопросе, возможно ли реализовать обнаружение зависимостей, загрузку и установку индивидуальных зависимостей в отдельные шаги, каждый из которых может быть завершен в каждой отдельной загрузке страницы

И наконец, стоит удалить все "придуманные здесь" библиотеки ядра в пользу зависимостей Composer-а (особенно это касается таких вещей, как JImage, JGithub и т. д.).

DI-контейнер

Ох, это - моя любимая мозоль. На настоящий момент у нас есть этот волшебный огромный черный ящик именнуемый JFactory. Нам стоит избавиться от JFactory, заменить его на DI-контейнер - (что-то вроде Pimple?) который затем поступает на объект приложения. Используя нечто вроде «Joomla\Application::getInstance()->getContainer()->user.», вы сможете получить и извлечь все что вам угодно.

Я также считаю, что я пошел несколько дальше. Так, на мой взгляд, каждый тип расширения должен получить свой собственный тип контейнера, который дает доступ к основному  DI-контейнеру и локальным зависимостям, которые имеют значение для конкретного типа компонента. Вы должны иметь возможность создать контейнер расширения из любого места, например, «Joomla\Container\Component::getInstance('com_something')». Это здорово подойдет для безболезненного HMVC. Были здесь, сделали это – в FOF 3.

Пересмотр MVC

Я знаю, что в Joomla! Framework существует "новый MVC", который я называю "не MVC", потому что это так и есть. Я не согласен с подходом его массового распространения для программного обеспечения, такого как Joomla! и ее расширений. Я понимаю, почему он может вам понадобиться для децентрализованных приложений. Я предлагаю оставить его в ядре и использовать для таких нужд, но не использовать его как парадигму развития Joomla! по умолчанию. Помните, что кто целевая аудитория? Вот именно.

Вместо этого, я предлагаю двигаться в направлении Laravel, но без использования фасадов – ведь это главная причина, почему некоторые серьезные PHP разработчики ненавидят Laravel. Давайте покончим с разделением Модель - Таблица. Это реально хорошая идея, создать Модель для не «data-aware» материалов и Модель Данных для «data-aware». используя словарь и набор функций, аналогичных для Модели Laravel + Eloquent. Я уже закончил свою работу в FOF 3 и сделал свой девелопмент проще. Меньше кода, быстрое выполнение, меньше ошибок и легче их исправлять, что реально очень здорово и выгодно.

Также, как я уже сказал выше, нужно поддержку языка Blade шаблонов в наши View. Меня очень соблазняет мысль, что можно будет позволять нашим View быть определенными XML формами, которые поддаются функциям RAD, таких как scaffolding– но если Вы не готовы чтобы RAD составлял основу ядра по умолчанию то это, по сути, нецелесообразно.

Ну, ладно, без разницы. Давайте просто внесем FOF 3 в ядро. Я уже знаю, каким будет самый большой недостаток для меня. Однако наличие RAD фреймверка в ядре это пойдет на пользу всем остальным. Сейчас мы разработчики страдают по Laravel, ZF и т. д. потому что так проще разрабатывать, хотя вам придется делать все с нуля. Если мы удалим чувство - "кодирование для Joomla! это ужас" - мы сможем вернуть огромную аудиторию. Эта аудитория может косвенно или напрямую повлиять на выбор платформы для новых сайтов крупного бизнеса, а ведь именно так мы планируем увеличить нашу долю рынка.

JSON API, в сущности, не код

Если бы мы могли разрешить доступ к данным CMS (и управлению данными), хотя бы как в JSON API, мы бы создали возможности продвинутого использования данной CMS. Например, используя Angular.js для отображения страниц, удаленного управления контентом, соединения с системой, простоты разработки мобильных приложений и др.

Фундамент для легкого JSON view с поддержкой HAL уже реализован в FOF. Неважно, станет он частью ядра или нет, поддержка HAL является тем, что мы должны добавить. Я знаю, что у нас уже есть com_ajax, но это полезно только для создания AJAX (как будто это снова 2008 год). HAL позволяет использующим API искать и использовать контент легче, без необходимости точно знать внутреннее устройство сервера.

Модернизация схемы установки и обновления

В этот момент каждое ядро базы данных изменение требует редактирования двух файлов - один для обновления в компоненте com_admin, и один для установки в приложении установки. Это может привести к ошибкам. Это проблема уже решена в FOF FOF30\Database\Installer с помощью XML-файлов, которые позволяют создавать код установщика и/или автоматически обновить схему. Это также упростило функцию исправления базы данных: Вы можете использовать тот же код, что установщик схемы/обновления.

Поскольку это уже обсуждалось в вопросах включения в Joomla! 3 я думаю, что это уже решено?

Улучшение установщика расширений

В прошлом году я написал официальный документ об этом. Мы можем и должны добавить поддержку подписи сборки. Некоторые пункты и характеристики работы уже сделаны David Jardin. Я уверен, что где-то существует и пересмотренный вариант, но я не могу его найти.

Я знаю, вы думаете, я закончу с этой большой темой всего в 30 слов. Но, эти два документа примерно в два раза больше, чем вся эта статья :)

Отделение меню от роутинга

Нынешняя система меню определяет пути роутинга и приводит к дублированию Контента, а также к некоторым проблемам, которые просто невозможно решить. Так, если конечный узел (например, материал) может быть открыт через два или более меню, то нет никакого способа, чтобы знать наверняка, какой URL-адрес следует использовать, если Вы к тому же не знаете, какой идентификатор элемента (Itemid) следует использовать. И если нет Itemid, то существуют шансы "неправильного" выбора, ведущего к подгрузке "неправильных" модулей.

Исправление этого МОЖЕТ вызвать некоторые проблемы с нашей системой модулей. Если каждый конечный узел имеет канонический URL, который вы может в конечном итоге опять получить отображение "неправильных" модулей в некоторых ситуациях. Например, если у меня есть пункт меню для всей категории и еще один пункт меню для одной из его статей (с разными назначением модулей), то, нажав на эту странную статью, мы увидим совершенно другой макет страницы, отличный от других статей из категории. Это не всегда плохо, но это не меняет ожидания пользователей по сравнению с Joomla! 3 и более ранних.

Наконец, com_redirect станет действительно важен, так как это будет самый простой способ, чтобы добавить пользовательские URL-адреса. В Joomla! 3 (и ее более ранних версиях) самый простой и типичный метод– создание элементов в скрытом меню (для которого нет опубликованных модулей).

На настоящий момент мне необходима обратная связь от людей, которые лучше разбираются в маршрутизации.

Тестирование и QA

Обновить PHPCS правила до PHPCS 2 формата. Это позволит участникам автоматически исправить стиль их кода (ужас нашего существования для больших сумм).

Модульный и функциональный тесты, в первую очередь, должны быть написаны для наших общих случаев использования. Краткосрочная цель - это не 80+% тестового покрытия, это убеждение в том, что регрессии не произошло.

Joomla! Framework

Я думаю, что теперь мы все можем признать, что попытка создать общий PHP фрэймверк, чтобы конкурировать с подобными Symfony, Zend Frameworkи т. д. - пустая трата ценных ресурсов. Так что же мы должны сделать с Joomla! Framework?

Первая идея, чтобы полностью направить его к ядру CMS, больше похожая на то, какой была Joomla! Платформа до того, как мы называли ее Joomla! Платформой. Я думаю, что это неправильный подход, потому что он связывает развитие CMS с развитием фрэймверка. Это не всегда хорошая идея. Фрэймверк – это, в основном, R&D. Вы просто не поставите R&D под разработку.

Лучший способ подход - несколько разделенный проект. Цель JF - обеспечить стабильную платформу для Joomla! (CMS), которая будет построена на нем. Это требует серьезных сдвигов в разработке JF, поскольку он должен иметь в виду и учитывать сложность массового распределенного кода. Например, пакет Uri просто не может проигнорировать необходимость в принудительной $live_site вместо консалтинга суперглобальной переменной $_SERVER. Но разделение его от CMS позволит не только осуществлять R&D в своем собственном темпе без ущерба для развития CMS, но также позволит всем заинтересованным использовать его за пределами CMS.

Что касается Joomla!, она может быть включена в JF сборки через Composer. Это должен быть один и единственный способ сделать это, а не как в текущей ситуации, когда создание нормальной человеческой копии возможно только через копирование .php файлов из миллиона git репозиториев в папку libraries/joomla.

Хотелось бы обсудить эти идеи с Andrew и Michael. Возможно, мы могли бы сделать совместный пост о будущем Фрэймверка. Я думаю, что если мы правильно сформируем фрэймверк, это может быть успешным дочерним проектом Joomla!. В общем, необходимо (пере)-определить целевую аудиторию и обсудить, как он может, наконец, сдвинуться вперед. 

Автор и оригинал статьи.