Symfony Flex — это современная замена установщика Symfony, а не название следующей версии Symfony. Как говорится во вступительном тексте:
Внутренне Symfony Flex — это плагин Composer, который изменяет поведение команд require и update. При установке или обновлении зависимостей в приложении с поддержкой Flex Symfony может выполнять задачи до и после выполнения задач Composer.
Новый Symfony будет называться просто Symfony 4, и хотя это руководство будет касаться только инструмента Flex, в нем также будут упомянуты некоторые обновления Symfony 4.
Все еще в разработке
Symfony Flex можно считать оболочкой Composer , поскольку он предоставляет вашему проекту Symfony дополнительные параметры во время установки и настройки. Он был разработан с учетом простоты и, очевидно, в значительной степени зависел от удобства Laravel. Помните, что Laravel достигла нынешнего уровня популярности благодаря простоте использования и низкому барьеру входа, который он предоставляет новичкам, и Symfony хотел подражать этому.
Следует отметить, что и Flex, и Symfony 4 все еще находятся в стадии разработки, выпуск которых запланирован на конец ноября этого года (2017 г.). Таким образом, некоторые функции, упомянутые в этом посте, могут измениться к моменту его прочтения, но мы сделаем все возможное, чтобы обновлять его.
В частности, использование make-файла и инструмента make для создания проекта, если Symfony / Console недоступна, все еще находится в стадии разработки, поскольку, похоже, он не работает должным образом в некоторых операционных системах. Недавно Фабьен провел опрос по этому вопросу, попросив предложения сообщества о замене, и в подавляющем большинстве случаев сообщество проголосовало за то, чтобы просто потребовать Symfony / Console.
Чем отличается?
В частности, Flex уважает грядущие обновления Symfony 4, которые сводятся к следующим основным изменениям:
- Требуется PHP 7+
- все папки являются необязательными. Если ваш проект не использует его, он не обязательно должен быть там. Это делает дерево каталогов намного проще и более читабельным. Кроме того, часто бесполезные файлы, такие как
.htaccess,LICENSEиREADME, также были удалены — проект, который нуждается в них, может легко их добавить. - нет больше
webпапки. Вместо этого естьpublicпапка, как и во всех других основных средах. Это консолидирует пользовательский опыт во всех экосистемах. - временные файлы находятся в
/varв корне папки проекта, а подпапка/var/cacheзарезервирована для долгосрочного кэша, например, файлы объединенных классов для развертывания приложений в качестве артефактов только для чтения - Исходный код находится в
/src. Нет/app - Конфигурация идет в
/config. - шаблоны идут в
/templates. - Flex будет иметь свой собственный список пакетов, проверенных Symfony, на которые ссылается только один псевдоним. Таким образом, выполнение
composer require cliфактически вызовет Flex, который найдет в своем списке пакетов, найдет тот, который помечен какcli(в данном случае Symfony Console), и установит его. Эти «официальные» пакеты называются рецептами, и их можно найти здесь . Для принятия пользовательских рецептов в конфигурации Flex существует флаг, для которого необходимо установить значение true:composer config extra.symfony.allow-contrib true. Эти рецепты можно найти здесь . Официально одобрив некоторые пакеты, Symfony во многом становится таким же самоуверенным, как и Laravel. Хотя в некотором смысле это плохо, во многих отношениях это очень хорошо: консолидированный и самоуверенный способ создания приложений Symfony, используемых большинством людей, чтобы все были на одной странице. - фрагменты пакета больше не нуждаются в пользовательской активации и добавлении в тонну файлов. Flex автоматизирует это, а также их удаление.
- вместо параметров в конфигурационных файлах Symfony 4 будет использовать переменные окружения, такие как Laravel
Бутстрапирование
Как обычно, мы предполагаем, что вы уже используете здоровую виртуальную среду, такую как Homestead Improved, чтобы вы могли следить за ней.
Хорошо, давайте запачкаем руки примером приложения. Все приложения Symfony теперь можно запускать из супер-минимального приложения Symfony Skeleton:
composer create-project symfony/skeleton flexy
Обратите внимание на созданную структуру каталогов.
В /public у нас больше нет app.php и app_dev.php , только файл index.php . Тип среды (test / dev / prod) теперь определяется переменными среды и считывает конфигурацию из папки /config .
Обратите внимание на то, как в конце процесса установки упоминается, что был вызван make cache-warmup , и что вы можете запустить make serve . Именно здесь новый Symfony использует «спорный» подход Makefile, упомянутый выше. Это может измениться.
Вне коробки открытие этого скелета в браузере приведет к ошибке, поскольку маршруты еще не определены. Давайте это исправим.
index: path: / defaults: { _controller: 'App\Controller\DefaultController::index' }
config/routes.yaml
Нам нужно создать этот контроллер и его действие index :
<?php namespace App\Controller; use Symfony\Component\HttpFoundation\Response; class DefaultController { public function index() { return new Response('Hello'); } }
Это создаст простой экран Hello, например:
Разрешения на выполнение
Если вы попытаетесь установить бинарный файл, такой как Symfony / Console, с помощью composer req cli , вы можете столкнуться со следующей проблемой:
~ bin/console -bash: bin/console: Permission denied
Это известный сбой при использовании виртуальных машин, который можно легко исправить одним из следующих способов:
- запустить консоль с помощью
php bin/consoleвместо прямого запуска, или - добавив разрешение «выполнить» к файлу на хост-машине (не из виртуальной машины), выполнив:
chmod +x bin/console. Это позволит сразу запуститьbin/consoleиз виртуальной машины.
Добавление пакетов
То представление «Привет», которое мы создали, выглядит обнаженным. Давайте добавим несколько шаблонов в микс.
composer req template
Мы можем использовать здесь template , twig , templates или templates , как определено в псевдонимах рецепта Twig .
Подход Symfony 4 / Flex автоматически активирует этот пакет для нас и создаст папку ( /templates ) с base макета, а также файл конфигурации ( config/packages/twig.yaml ).
Теперь мы можем свободно определять представление для нашего маршрута Hello:
{% extends '../base.html.twig' %} {% block body %} {{ greeting }} {% endblock %}
/templates/default/index.html.twig
Теперь мы можем изменить контроллер, чтобы он возвращал это вместо простого текстового ответа:
<?php namespace App\Controller; use Symfony\Bundle\FrameworkBundle\Controller\Controller; class DefaultController extends Controller { public function index() { return $this->render('default/index.html.twig', ['greeting' => 'hello']); } }
Обратите внимание, как нам пришлось расширить контроллер FrameworkBundle , чтобы получить доступ к методу render , но это было обо всей добавленной конфигурации, которую мы должны были сделать. Наш привет маршрут теперь намного круче.
Большие связки
Теперь давайте попробуем добавить большой пакет, включающий несколько других. Пакет admin для создания бэкэндов является хорошим вариантом. Кроме того, это одна из тех команд, которые Symfony решила официально одобрить, и она использует рецепт orm , который ссылается на Doctrine — еще одну рекомендацию Symfony (можете ли вы увидеть опрометчивость в действии?)
composer req admin
Нам нужно будет создать сущность, прежде чем мы сможем использовать пакет администратора. Для этого нам нужна база данных. Создайте новую базу данных и пользователя. Этот процесс должен быть в порядке:
mysql -u homestead -psecret create database flexy character set utf8mb4 collate utf8mb4_unicode_ci;
Не стесняйтесь создавать базу данных конкретного пользователя тоже, если вы чувствуете, что это необходимо. Затем измените файл .env чтобы он соблюдался:
DATABASE_URL="mysql://homestead:[email protected]:3306/flexy?charset=utf8mb4&serverVersion=5.7"
Наконец, давайте создадим объект. Предположим, мы создаем сайт, который позволяет пользователям отправлять на сайт информацию — например, Reddit, ссылки для отправки, например. У нас будет объект под названием «Представление», например:
<?php namespace App\Entity; use Doctrine\ORM\Mapping as ORM; /** * Class Submission * @package App\Entity * * @ORM\Entity * @ORM\Table(name="submission") */ class Submission { /** * @ORM\Column(type="integer") * @ORM\Id * @ORM\GeneratedValue(strategy="AUTO") */ public $id; /** * @ORM\Column(type="string", length=255) */ public $name; /** * @ORM\Column(type="string", length=255) */ public $url; /** * @ORM\Column(type="text") */ public $description; }
Сущность должна быть зарегистрирована в файле config/packages/easy_admin.yml :
easy_admin: entities: - App\Entity\Submission
Теперь у нас будет Doctrine для создания этой таблицы для нас.
bin/console doctrine:schema:update --force
Обратите внимание, что вы также можете сделать так, чтобы Doctrine создала базу данных, если она не существует. Посмотрите на doctrine:database:create для этой функциональности.
Если мы сейчас посетим URL /admin нашего приложения, мы должны увидеть что-то вроде этого:
Добавление материалов теперь должно работать как шарм:
Неофициальные комплекты
А как насчет пакетов, которые официально не поддерживаются Symfony?
Для этого нам нужно щелкнуть переключатель Composer.
composer config extra.symfony.allow-contrib true
Это также позволит извлекать рецепты из этого хранилища . Допустим, мы хотим, чтобы в наших представлениях был идентификатор uuid вместо простого целого числа с автоматическим увеличением. Для этого мы можем использовать пакет UUID-Doctrine от Ramsey . При запросе рецептов contrib они обычно не имеют псевдонимов, и на них нужно ссылаться полностью, как в обычных пакетах.
composer req ramsey/uuid-doctrine
Поскольку это пакет, созданный сообществом, Symfony выдаст вам предупреждение, как только загрузит его.
Примечание. Репо Contribute — это отличный фильтр мертвых пакетов и пакетов — каждый разработчик пакетов / пакетов, который заботится о своей работе, перенес его туда, так что вы можете быть уверены, что разработка недостающих пакетов остановилась.
После установки пакета мы можем использовать его в нашем проекте.
Во-первых, мы должны сказать Doctrine, что она теперь доступна (что, по моему мнению, должен делать сам рецепт — пока недостаточно автоматизировано!):
doctrine: dbal: url: '%env(DATABASE_URL)%' types: uuid: Ramsey\Uuid\Doctrine\UuidType orm: ...
config/packages/doctrine.yaml
Затем мы изменим сущность Submission, чтобы использовать этот тип в атрибуте id :
... class Submission { /** * @var \Ramsey\Uuid\Uuid * * @ORM\Id * @ORM\Column(type="uuid", unique=true) * @ORM\GeneratedValue(strategy="CUSTOM") * @ORM\CustomIdGenerator(class="Ramsey\Uuid\Doctrine\UuidGenerator") */ public $id; ...
Теперь давайте обновим базу данных и очистим текущие объекты:
bin/console doctrine:schema:drop --force bin/console doctrine:schema:update --force
Наконец, давайте попробуем повторно посетить /admin и добавить новую сущность.
Конечно, у нашего нового объекта есть UUID для первичного ключа.
Примечание: рекомендуется использовать другой тип при использовании UUID для первичных ключей в базах данных типа InnoDB, но для краткости мы использовали значение по умолчанию. Полные инструкции здесь .
Добавление сторонних инструментов
Другие сторонние инструменты можно использовать так же, как и раньше — только они не будут автоматически настраиваться Flex. Вам придется зарегистрировать их вручную и удалить их таким же образом. Поэтому рекомендуется переместить любой пакет, который нуждается в дополнительной настройке для бесперебойной работы с Symfony, в contrib рецептов contrib , чтобы другие могли получить выгоду от более плавного рабочего процесса Flex.
Вывод
Symfony Flex — это современный способ установки и управления приложениями Symfony, и это красная дорожка перед дверью Symfony 4. Излишне говорить, что мы очень взволнованы недавним набегом Symfony на современную разработку и область высоких DX, и мы будем пристально следить за этим. Мы надеемся, что вы нашли это введение полезным!
Мы не сравнивали этот конечный результат с другой платформой просто потому, что это не имеет смысла, когда вы рассматриваете возможные варианты оптимизации, которые вы можете выполнить, а также потому, что у нас есть месяц производительности (весь ноябрь), в течение которого мы будем поглощать всевозможные проблемы, связанные с производительностью, и пройдитесь по целому набору методов, которые вы сможете применить к своим проектам — независимо от структуры или типа приложения. Будьте на связи!