В этой статье мы увидим перспективы Joomla 4 для разработчиков, а также определим вид архитектуры РНР-кода и задачи дизайна.
Доступность
Уже говорилось, что Joomla требуется улучшение доступности. По всей видимости, это необходимо для Joomla в государственном секторе многих стран. Думаю для этого необходимы предложения от экспертов в данной сфере.
Современный CSS фреймворк
Joomla 3 на годы застряла в Bootstrap 2.Но что еще хуже, это даже не Bootstrap, это собственно неудачная его версия. МОжет быть, это имело смысл в 2011 году, но в 2015 это всеравно, что пытаться использовать для сообщения сигнальные огни, когда все остальные используют текстовые сообщения. Нам нужен современный, актуальный CSS фреймворк.
Существует 2 мнения по этому вопросу. По первому мнению, мы должны развивать наш собственный СSS фреймворк. Мы не согласны с этим подходом, поскольку он требует редкого таланта, которого у нас и сейчас мало, и не факт, что будет больше в будущем. Простыми словами, это не самая лучшая идея, если вы не можете гарантировать долговечность такого проекта.
По второму мнению - обзавестись парой для Joomla было очень эффективно. Bootstrap - это замечательный фреймворк, и мы должны его придерживаться. Однако немаловажно всегда использовать последнюю версию, выпущенную не позднее 6 месяцев, чтобы соответствовать циклу разработки Joomla. Мы НЕ должны бояться нарушить обратную совместимость при обновлении до последней версии Bootstrap.
JLayout - залог успеха
JLayout это отличный способ отделить некоторые из сложностей использования различных CSS фреймворков. Но нужно помнить, что это касается толькостатичного контента, а не JavaScript взаимодействий, которые требуют знания:
- Использования DOM-модели фреймворка.
- Доступности вспомагательных функций JavaScript.
По сути, JLayout это HTML уровень абстракции.
Что если бы мы могли использовать JLayout, чтобы подгружать JavaScript абстракции? Некоторые JLayout шаблоны уже практически могут загружать свои скрипты, но только для решения задач ядра Joomla. Если сторонний разработчик, который хочет динамически отображать кнопки или изменять цвет ярлыка на ленту, хоть и на JavaScript, то его единственный вариант сейчас - создать AJAX-вызовы , которые создадут новую HTML-страницу и заменят содержимое той страницы, которую пользователь просматривает в данный момент. Это неправильно и нецелесообразно по многим причинам!
Давайте развивать общую библиотеку JavaScript, проксирующую Bootstrap. Если разработчики решщат использовать СSS фреймворк XYZ - они обязаны предоставить переопределение для этой общей библиотеки JavaScript. Это позволит сторонним разработчикам поддерживать разные шаблоны без ужасной грубой подгрузки Bootstrap с пространством имен или без изобретения своих собственных CSS-фреймворков, которые не выглядят правильно в сторонних шаблонах.
Смена вида шаблонов
Одним из новшеств Joomla 1.5 было внедрение вида шаблонов, который отделил код, который создает материалы от кода, который их отображает. Это было здорово, но.. это было здорово 9 лет назад. Вы давно смотрели на наши шаблоны? В них чоень много РНР-кода. Фронт-энд разработчик должен иметь гораздо больше, чем поверхностное представление о РНР для стилизации.
Между тем в РНР-мире появился Laravel. И в нем ну совсем просто понять ег Blade-шаблоны. И он сделал прорыв. Он невероятно мощный и, ко всему прочему, легкий для интерфейсного разработчика, ведь чтобы понять и настроить РНР, не надо вдаваться в конкретику. И да, Laravel может быть протирован на Joomla.
Синтаксис Blade позволяет нам упростить жизнь разработчиков еще больше, добавив поддержку для конструкций типа @ilayout('com_example.foo.bar',$this->items,$somethingElse). Сравните это с типичным JLayout вызовом кода ядра и вы увидите, куда это идет.
РНР 5.4 и выше
РНР 5.3 мертв с августа 2014. РНР 5.4 будет мертв в августе 2015 года, но, по крайней мере, мы знаем, что все общие хосты поддерживают его- за исключением тех, которые не должны быть подключены к Интернету - по крайней мере в качестве опции.
РНР 5.4 позволяет нам писать код компактнее и с меньшим дублированием, используя трейты. Это и есть практическая причина, стоящая за этим предложением. Мы могли бы избавиться от 15% наших ключевых компонентов кода и уменьшить количество ошибок, с которыми приходится иметь дело.
Только MySQL (и совместимые варианты)
Это не устроит тех 10 человек, которые используют Joomla с Microdoft SQL Server и PosgreSQL. Существует несколько практических причин для этого, а менно:
- Оптимизация запросов. Наши запросы не являются оптимальными и приводят к плохой производительности, особенно на больших сайтах. Если мы знаем, что ядром предполагается работа только с MySQL, мы можем использовать MySQL опыт администраторов БД сообщества Joomla с долгосрочным предложением помочь, чтобы сделать Joomla быстрее. Это станет отличным инициативным преимуществом и классным маркетинговым ходом.
- Снизить порого вхождения и ошибки в деплойменте. Если кто-то поставляет новую функцию с изменениями схемы, то оон должен внести эти изменения в формат MySQL, PostgreSQL и MSSQL-сервера. Каждый в 2 разных местах. Это ставит в тупик разработчиков, которые очень опытны в РНР и MySQL, но не могут себе позволить вновь и вновь учиться и тестировать СУБД PostgreSQL и MS SQL сервер. но что еще хуже, изменения схемы Postgre SQL и MS SQL Server обычно объединяются непроверенными, и ошибки можно обнаружить только спустя долгое время после релиза.
- У нас нет людей, чтобы поддержать 3+ различных технологий сервера. Доказательством является то, что в Postgre SQL интеграция была сломана очень долгое время (минимум 1 год) и исправить это.
- Так что давайте прекратим поддержку дополнительных типов баз данных. М ы можем оставить для них драйверы в ядре для использования сторонними разработчиками и корпоративными пользователями. Ядро будет поддерживать рабботу только под управлением MySQL.
- Что же касается самой MySQL, с тех пор как мы еще не можем повысить минимальное требование до MySQL 5.6, нам пока придется иметь кучу проблем с тем, что основным таблицам нужна поддержка полнотекстового поиска, привязанная к MyISAM.
Избавиться от UCM
UCM всегда был готовым только наполовину, и навсегда таким останется, так что давайте просто избавимся от него. Он не требуется для тегов и содержимого версий. Нам просто нужны таблицы с назначением тегов и контента, а также одно дополнительное поле, обозначающее тип контента. Затем мы можем использовать что-то вроде используемых в Laravel отношений "morphable", чтобы все это работало. Если вы почитаете Laravel документацию, то в любом случае, вы увидите, в конце концов, что использовать кейс morphable отношений - это отличный вариант.
Дополнительный плюс - это значительно уменьшает дублирование и нагромождение из основных таблиц, упрощает запросы и ускоряет работу.
Удалить большое количество расширений кода
Но согласно существованию плана. Сейчас мы проигрываем как минимум одной ыещи, а именно в рекламе для наших пользователей расширений, поддерживаемых ядром. Страница "Установить из Сети" должна иметь две зоны - поддерживаемые ядром расширения и список наиболее популярных JED категорий. Это позволяет нам сказать пользователям, куда пойти, чтобы быстро добавить функции, которые они не нашли в ядре. Этот подход прекрасно работает для WordPress: страница "Добавить плагин" - это, по сути, автоматически сформированный список или список спонсируемых плагинов.
Пространства имен везде
Так как это основная версия, есть надежда, что мы можем окончательно разорвать обратную совместимость и создать полноценный ко пространства имен. Это также позволит упростить наш код, так как это будет наконец-то возможность отделить фронтэнд MVC класс от бэкэнд MVC класса. Ранее это было просто невозможно, так как они оба носили одинаковое имя.
Кроме того мы можем полностью покончить с JLoader. Вместо этого, можно использовать PRS-4 от Joomla Composer - автозагрузчик, который уже идет вместе с Joomla. Это позволит избавиться от ошибок кода сторонних разработчиков, вызванных перемещением классов ядра из libraries/joomla в libraries/cms, либо классов, не следующих текущей схеме автозагрузчика.
Обратная совместимость слоя, по крайней мере, для 4.х
Новая версия CMS бесполезна бехз расширений сторонних разработчиков, облегчить переход из кода, написанного для Joomla 3 на
Joomla 4. Это может быть реализовано путем создания слоя совместимости, который добавляется к классам алиасов и бэкпортов устаревшего кода для наиболее часто используемых базовых интерфейсов API. Это позволит разработчикам продолжать свой путь в направлении совместимости
Joomla4 без страха, что им придется все начинать с нуля.
А если бы мы задокументировали процесс преобразования для существующего кода, то, ко всему прочему, смогли бы получить отличные дивиденты.
Улучшенная интеграция Composer
НЕобходимо переместить composer.json и composer.lock в папку libraries/vendor. Это позволит добавлять требования без существенного вмешательства в ядро.
Это также позволит сторонним разработчикам добавлять требования для установки в Joomla Composer во время установки/обновления расширений. Нам нужно увидеть, что это возможно на общих узлах без CLI доступа - как пример стоит посмотреть это Drupal 8 обсуждение. Это требует привязки к общему рефакторингу com_installer. Однако изучение осуществимости задачи должно сосредоточиться на вопросе, возможно ли реализовать обнаружение зависимостей, загрузку и установку индивидуальных зависимостей в отдельные шаги, каждый из которых может быть завершен в каждой отдельной загрузке страницы.
И наконец стоит удалить все "придуманные здесь" библиотеи ядра в пользу зависимостей Composer-a.
DI-контейнер
На этот момент у нас есть это черный ящик именуемый JFactory. Нам тоит избавиться от него, заменить его на DI-контейнер - который затем поступает на объект приложения. Используя нечто вроде «Joomla\Application::getInstance()->getContainer()->user.», вы сможете получить и извлечь все что вам угодно.
На наш взгяд, каждый тип расширения должен получить свой собственный тип контейнера, который дает доступ к основному DI-контейнеру и локальном зависимостям, которые имеют значение для конкретного типа компонента. Вы должны иметь возможность создать для конкретного типа компонента. Вы должны иметь возможность создать контейнер расширения из любого места, например, «Joomla\Container\Component::getInstance('com_something')». Это здорово подойдет для безболезненного HMVC.
Пересмотр MVC
В Joomla Framework существует "новый MVC", который мы называем "не MVC", потому что это так и есть. Мы не согласны с подходом его массового распространения для программного обеспечения, такого как Joomla и ее расширений. Нам понятно почему он может вам понадобиться для децентрализованных приложений. Мы предлагаем оставить его в ядре и использовать для таких нужд, но не использовать его как парадигму развития Joomla по умолчанию.
Вместо этого, мы предлагаем двигаться в направлении 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, мы бы создали возможности продвинутого использования данной СMS. Например, используя Angular.js для отображения страниц, удаленного управления контентом, соединения с системой, простоты разработки мобильных приложений и др.
Фундамент для легкого JSON view с поддержкой HAL уже реализованы в FOF. НЕважно, станет он яастью ядра или нет, поддержка HAL является тем, что мы должны добавить. Я знаю, что у нас уже есть com_ajax, но это полезно только для создания AJAX. HAL позволяет использующим API искать и использовать контент легче, без необходимости точно знать внутреннее устройство сервера.
Модерация схемы установки и обновления
В этот момент каждое ядро БД изменение требует редактирования двух файлов - один для обновления в компоненте com_admin, и один для установки в приложении установки. Это может привести к ошибкам. Эта проблема уже решена в FOF FOF30/Database/Installer с помощью XML-файлов, которые позволяют создавать код установщика и /или автоматически обновить схему. Это также упростило функцию исправления БД: вы можете использовать тот же код, что установщик схемы/обновления.
Отделение меню от роутинга
Нынешняя система меню определяет пути роутинга и приводит к дублированию Контента, а также к некоторым проблемам, которые просто невозможно решить. Так, если конечный узел может быть открыт через два или более меню, то нет никакого способа, чтобы знать наверняка, какой URL-адрес следует использовать, если вы к тому же знаете, какой идентификатор элемента следует использовать. И если нет Itemid, то существуют шансы "неправильного" выбора, ведущего к подгрузке "неправильных" моделей.
Исправление этого может вызывать некоторые проблемы с нашей системой модулей. Если каждый конечный узел имеет кононический URL, который вы можете в конечном итоге опять получить отображение "неправильных" модулей в некоторых ситуациях. Например, если есть пункт меню для всей категории и еще один пункт меню для одной из его статей, то, нажав на эту странную статью, мы увидим совершенно другой макет страницы, отличный от других статей категории. Это невсегда плохо, но это не меняет ожидания пользователей по сравнению с Joomla 3 и более ранних.
Наконец, com_redirect станет действительно важен, так как это будет самый простой способ, чтобы добавить пользовательские URL-адреса. В Joomla 3 самый простой и типичный метод-создание элементов в открытом меню.
Тестирование и QA
Обновить PHPCS правила до PHPCS 2 формата. Это позволит учасникам автоматически исправлять стиль их кода.
Модульный и функциональный тесты, в первую очередь, должны быть написаны для наших общих случаев использования. Краткосрочная цель - это не 80+% тестового покрытия, это убеждение в том, что регрессии не произошло.
Joomla Framework
Теперь можно признать, что попытка создать общий РНР фреймворк, чтобы конкурировать с подобными Symfony, Zend Frameworkи т.д. - пустая трата ценных ресурсов. Так что же нам делать с Joomla Framework?
Первая идея, чтобы полностью направить его к ряду CMS, больше похожа на то, какой была Joomla платформа до того, как мы называли ее Joomla Платформой. Есть мнение, что это неправильный подход, потому что он связывает развитие CMS с развитием фреймворка. Это не всегда хорошая идея. ФРеймворк - это, в основном, R&D. Вы просто не поставите R&D под разработку.
Лучший подход - несколько разделенный проект. Цель JF - обеспечить стабильную платформу для Joomla, которая будет построена на нем. Это требует серьезных сдвигов в разработке JF, поскольку он должен иметь в виду и учитывать сложность массового распределенного кода. Например, пакет Uri прото не может проигнорировать необходимость в принудительной $live_site вместо контсалтинга суперглобальной переменной $_RIVER. Но разделение его от СMS позволит не только осуществлять R&D в своем собственном темпе без ущерба для развития СMS, но также позволит всем заинтересованным использовать его за пределами CMS.
Что касается Joomla она модет быть включена в JF сборки через Соmposer. Это должен быть один и единственный способ сделать это, а не как в текущей ситуации, когда создание нормальной человеческой копии возможно только через копирование .РНР файлов из миллиона git репозиториев в папку librares/joomla.
