Как стать автором
Обновить

Комментарии 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.
Заинтриговало, однако, я так и не понял как именно мне поможет Symfony Flex. В техническом плане. За счет чего он сэкономить мне время… flex будет каким-то магическим образом прописывать для меня нужные конфиги бандлов? Или же с легкостью удалить ненужные пакеты из проекта в один клик?

Лично в моей практике добавление/удаление бандла занимает примерно 0.1% от общего времени работы над проектом. А вот рефакторинг кода после такой операции берет действительно много времени. Но разве флекс способен в этом помочь? Не думаю. В общем вопрос много, ответов нет, ждем продолжение статьи.
Ну вряд ли нам конечно предоставят какой нибудь ИИ, который будет делать за нас все + еще и тапки приносить. Скорее всего произойдет снятие определенных рамок и немного философии о свободе прав кода и правильной расширяемости приложения. Symfony Flex будет давать возможность управлять приложением гибко (на то он и Флекс), позволит наращивать только в нужном направлении, т.е. не иметь никаких стен.

Пример даже из статьи, если нам нужен 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 для меня еще упростит эту задачу.

Навскидку у вас там ненужные вам доктрина, монолог, свифтмэйлер, твиг.

Интересная вскидка. Доктрина, монолог нужны как в админке так и в АПИ. "свифтмэйлер, твиг." нужны в админке. Но даже если бы и не были нужны, суть то вопроса вообще не в этом. Я могу их отключить, довольно быстро, буквально минут 10-20 времени.

Собственно это было сделано мной. Когда обращение идет к АПИ ни твиг, ни сфитмейлер не подгружаются. И наоборот когда обращаемся к админке, бандл FOSRestBundle не подгружется.

Вы на это не указали. У меня сейчас не меньше трети проектов в продакшене, которые используют максимум монолог.

имхо


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)

Эта новая штука flex, как мне кажется, — нечто похожее на symfony installer по философии появления. Последний появился для того, что бы не писать create-project и не ждать пока composer решит зависимости, а набрать new и получить снапшот (если я не ошибаюсь) каркаса быстро. Типа сахар, только не синтаксический, а терминально-командный. А на практике я еще ни разу (кроме теста из любопытства) не пользовался этим инсталером.
Аналогично. Первая мысль, которая придет мне в голову, если я начну клепать сайты на симфони раз в неделю — это сделать свой отдельный пакет и разворачивать его через create-project
  • Загрузка необходимых зависимостей через composer require symfony/bundle
  • Регистрация бандла в app/AppKernel.php
  • Регистрация маршрутов, которые предоставляет наш новый бандл, если таковые имеются
  • Регистрация необходимых настроек для бандла в app/config/config.yml

Реализовал в своем проекте пункты 2, 3, 4 несколько лет назад (кажется году эдак в 2013). На основе этого функционала сделал систему плагинов в приложении, а потом еще добавил систему обновлений (self-update).
И сводилось все действительно к одно команде:


composer require vendor/depdency

Планировал написать об этом статью на хабре, но руки так и не дошли.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.