Comments 21
В этой части
У Symfony достаточно громоздкий процесс установки внешних бандлов
Упущен довольно важный кусок из истории возникновения composer-а
Fun fact: Composer started as a conversation about how to generically install bundles/plugins/extensions for Symfony and phpBB.
WTF fact: Neither Symfony nor phpBB uses Composer as a way to install its bundles/plugins/extensions.
Лично в моей практике добавление/удаление бандла занимает примерно 0.1% от общего времени работы над проектом. А вот рефакторинг кода после такой операции берет действительно много времени. Но разве флекс способен в этом помочь? Не думаю. В общем вопрос много, ответов нет, ждем продолжение статьи.
Пример даже из статьи, если нам нужен REST + Admin, то мы больше не будем нуждаться в целом дистрибутиве под это дело, т.к. теперь мы можем свободно нарастить наше приложение, добавив как REST, так и Admin — и всё это без мяса и с львиной долей гуманизма и жвачки. Композицию наследованию!!!
«Symfony Flex должен привнести к искоробочности еще и гибкость выбора» — цитата одного из разработчиков в чате.
Ну вот опять же. Буквально сейчас пишу проект в котором Admin Panel + API. Что я сделал, взял стандарт эдишет, накатил FOSRestBundle, сконфигурировал его. Потратил часа два времен. После двух недель работы над эндпоинтами заказчики приняли решение, что нужна админка. Накатил FOSUserBundle, сконфигурировал его. Что бы код для эндпоинтов не пересикался с админкой, завел новый фронтконтроллер и отдельные для него конфиги (те в проекте есть фронконтроллеры app_api.php app_admin.php и конфиги config.yml config_api.yml config_admin.yml не буду тут подробно расписывать).
Я это к тому, что на мой взгляд я и сейчас отлично наращиваю функционал в нужном мне направлении, при этом довольно гибко и легко как по мне. И мне как-то воображения (или знаний) не хватает, что бы хотя бы примерно представить, как же Flex для меня еще упростит эту задачу.
Навскидку у вас там ненужные вам доктрина, монолог, свифтмэйлер, твиг.
имхо
composition over inheritance
как попытка упростить работу с symfony приложениям имеют опосредованное отношение, редкий бандл заставляет наследоваться от изкоробочных компонент\сервисов. Как правило, можно всё завернуть в нужный алиас или не очень геморно перегрузить
Конечно же, если обсуждать этот принцип сам по себе, то его достоинства и минусы очевидны и сейчас, имхо, он более уместен, чем, например, лет 5-10 назад.
А вот рефакторинг кода после такой операции берет действительно много времени.
Это как простите?
Типа был у вас код который был завязан на пакет А и мы решили перейти на пакет Б и для этого придется переписать/написать новые адаптеры? Ну ок, этот процесс не автоматизируется никак. Но это и не "рефакторинг". Рефакторинг это когда у вас были размазаны зависимости по коду и вы решили перейти на другую библиотеку и для этого применили инверсию зависимостей и работу с библиотекой зашили в свой адаптер.
Спасибо. Действительно, "рефакторинг" неподходящее слово. Но я писал немного о другом, вы не за ту часть текста зацепились. Добавлять/удалять плагины мне и сейчас вполне удобно, и если флекс улучшит этот аспект, то на мой взгляд, это незначительное нововведение.
Добавлять/удалять плагины мне и сейчас вполне удобно
Процесс добавления бандла в симфони очень простой. Но он достаточно сложен что бы люди воротили свои сборки куда включают даже те зависимости которые могут пригодиться на одном проекте из четырех. То есть сейчас процесс добавления/удаления зависимостей может и занимает у вас 0.1% от времени разработки (хотя больше, уверяю, надо ж еще документацию почитать да настроить) но упрощение этого процесса увеличит степень реюза кода.
К примеру есть пара бандлов для организации oauth аутентификации и т.д. Они требуют настройки. Более того, большинство из тех что я видел ориентируются на старые добрые web странички и если access token придет вам в готовом виде с клиента 80% кода библиотеки можно выкинуть. А сделать удобную обертку опять же в виде бандла уже будет не так тривиально, так как надо уже говорить разработчику "а вот тут подключи два бандла и строго в таком порядке".
Так же часто ловлю разработчиков на том что они часто пишут велосипеды потому что "ну это ж надо бандл найти, подключить, проверить… лень… тут же 5 минут самому написать".
С симфони плохо знаком, но в ларе такой же подход унаследован — стянул пакет, затем подключил в конфиге. Для минимизации рутинных действий с конфигами и всякими ассетами есть консольная команда (vendor:publish), но подключение сервис-провайдера в ядре не избежать, да это и логично: может у меня в зависимости от окружения разный набор пакетов подключается.
Сдаётся мне, что все фреймворки (соответствующие ообщества), которые в той или иной степени используют symfony-компоненты, должны разработать PSR для для публикации и подключения компонентов, на основе которых можно будет пилить как базовые скрипты (в композере или в конкретном фреймворке), так и кастомные (в конкретном проекте). Тогда можно будет говорить о реальном упрощении всей этой катавасии с подключением\отключением
А еще вот мне например до сих пор не открылся баланс между упрощением инсталляции (вшитое дефолтное поведение) и наглядностью (инструкция по подключения). Очевидно, что полностью из коробки процесс инсталляции как и подробная но самостоятельная возня в среднем не подходят для всех участников\пользователей.
composer require --dev vendor/dev-depdency
composer require vendor/depdency
Скорей всего ядро будет ориентироваться только на прямые зависимости. Автоконфигурация будет производиться тоже за счет наличия явно подключенного пакета.
Например есть компонент symfony/form. При его наличии в секции require будет происходить установка ключа framework.forms в положение ~. Аналогично, если установлен метапакет, замещающий symfony/form (например, symfony/symfony)
Это уже реализовано в 3.3-dev. Аналогично можно поступать с другими пакетами. Бандлам, я полагаю, будет предложено иметь «дефолтную конфигурацию» и\или иметь стандартные точки расширения, например какой нибудь symfony/security-bundle с помощью symfony/doctrine-bridge может найти единственную сущность, имплементирующую UserInterface и автоматически подключить в качестве провайдера пользовательских аккаунтов. Zero-configuration.
Фантазировать можно много, идея в целом годная. Остается только ждать )
Кстати да. на этот случай же уже есть секция bin (копирование все этих скриптов из пакета в проектный bin) к композере. если я ничего не путаю, к этому делу можно добавить условно безопасный запуск всего, что есть в проектном бине и будет уже что-то с чем можно работать. не надо перехреначивать конкретный фреймворк… на самом деле надо, конечно, но по другой причине 8)
- Загрузка необходимых зависимостей через composer require symfony/bundle
- Регистрация бандла в app/AppKernel.php
- Регистрация маршрутов, которые предоставляет наш новый бандл, если таковые имеются
- Регистрация необходимых настроек для бандла в app/config/config.yml
Реализовал в своем проекте пункты 2, 3, 4 несколько лет назад (кажется году эдак в 2013). На основе этого функционала сделал систему плагинов в приложении, а потом еще добавил систему обновлений (self-update).
И сводилось все действительно к одно команде:
composer require vendor/depdencyПланировал написать об этом статью на хабре, но руки так и не дошли.
Symfony Flex, как будет выглядеть ваше приложение с Symfony 4