Symfony 5 что нового
Symfony 5.0
Сегодня на конференции SymfonyCon в Амстердаме был представлен пятый релиз свободного php-фреймворка Symfony, использующего модель MVC. В списке использующих Symfony проектов есть достаточно много популярных веб-приложений, таких как Drupal (CMS), Joomla (CMS), Facebook (SDK), Google API (SDK), phpBB, phpMyAdmin и другие. Среди 269 нововведений можно выделить 2 новых компонента:
Можем поздравить команду. Фреймворк явно слизывает тот же Spring, но на PHP. Работать с фреймворком приятно, документация нормальная. Но исходный код ужасный.
Мы на одном из проектов используем компоненты Symfony, при том проект был из 2000х и мы просто выкидывали велосипеды, заменяя на компоненты. Само собой делалось это постепенно и через адаптеры.
Да, кстати как-то сбоку в четверке был прикручен PSR-7, сам Request его не поддерживал. Как там сейчас дела?
да, я тоже хотел бы, чтобы в PHP была работа со строками как в Ruby из коробки
Нужно. Единственное сообщество, позитивно влияющее на развитие PHP. Чего стоит их умение писать независимые компоненты, которые применяются почти в каждом проекте
емнип symfony вообще вышли из PHP FIG, так что резонно ожидать, что на некоторые PSRы вообще забьют
что за возмутительная чушь, есть пруфы? Примеры инженерного гения в других проектах?
Отличный там код. Особенно в сравнении с Yui2 и Laravel
Да, погуглите как сделать аутентификацию пользователя средствами Symfony. Далее в контроллере есть методы getDoctrine(), далее почитайте код Request’a В симфони уже сейчас огромный слой Легаси.
Эм, но Laravel на половину состоит из Symfony, а Yii2 красиво написан, но монолит, за что получил по шапке. Да и много было архитектурных промахов, вроде jQuery в зависимостях.
Я об этом. Они почему то остались в своем мире. Это может не очень хорошо кончиться.
как минимум там нет mb*-костылей и крутой method chaining (причём не только для строк)
Yii2 красиво написан, но монолит, за что получил по шапке
Он не монолит. Там проблема в другом, у них свой DI-контейнер и своя автозагрузка, поэтому нельзя их компоненты использовать отдельно и наоборот, притащить что-то из symfony. В Yii3 обещают всё перепилить под PSR, так что будет всё пучком.
Там всё в кучу свалено. Это ещё хуже.
крутой method chaining (причём не только для строк)
Монада пишется на коленке за 5 минут.
app() можно абсолютно из любой части кода (вне зависимости от слоя абстракции приложения) получать инстанс приложения, что как бы не совсем ок.
Это спорное утверждение.
мне кажется пора бы уже на composer + artisan переходить с этого мамонта
пока не начинаешь проект тестами покрывать
И чем мешает app()? Это тот же DI, только императивный, а не декларативный.
Раз уж тут собрались специалисты, можете сказать как мне сделать ucfirst в утф?
Пусть эти господа идут куда подальше. Для пыха локатор ничем не хуже DI на свойствах и т.п. потому что всё равно всё происходит в рантайме. Т.е. между
я не вижу никакой особой разницы, кроме вкусовщины.
можете сказать как мне сделать ucfirst в утф
Да меня устраивает, просто php6 отменили вроде как раз из-за юникода, а теперь 7 и чето не видно все еще в роадмапе.
Впрочем, в разных фреймворках есть свои благородные способы. Норм, конечно, давайте тащить замену из сторонних фреймворков на замену нативной нерабочей функции. Я за php, если что.
Вопрос таки как раз не вкусовщины. Это неявная зависимость. Разработчики используют сервис локатор в коде бизнес логики, и используют эту самую неявную зависимость. Тестировать такой код становится сложнее, а перенести в другие системы так вообще невозможно.
Поздравляю симфонистов. Я Symfony не использую, но на текущее время, это единственный адекватный фреймворк в мире PHP. Со своими заморочками конечно.
Еще жду когда выкатят Laminas (продолжение Zend Framework).
Он не монолит. Монолит. Достаточно посмотреть структуру классов. У них все от Component наследуется и по всему коду есть Yii::$app
Мы не говорим про использование Yii2 AR, а про то, как сам AR внутри написан.
Состоит, но только в Ларавеле через app() можно абсолютно из любой части кода
За это руки отрывают во второй рабочий день.
Что не так аутентификацией? Используешь сервис authentificationUtils для простой формы, для чего-то посложнее, используешь AuthentificationManager. Что с request? Вполне удобная реализация, особенно аттрибуты. GetDoctrine никто кроме новичков больше не использует, обычно инджектят репозиторий как сервис. Если Вы видите в иде зачеркнутый и неудаленный метод, это не значит что это плохо, это оставлено специально для совместимости пользователям с легаси проектами
А если в глубине дочерних сервисов нужно инициализировать другой сервис, когда уже использовано достаточно памяти инициируя родительские, локатор будет снова поднимать и ресолвить контейнер, что может спровоцировать закрытый out of memory, в отличие от DI
Там всё в кучу свалено. Это ещё хуже.
Монада пишется на коленке за 5 минут.
можно и обвёртку накатить за ★★★★★ ( 22.11.19 11:36:03 )
Последнее исправление: Ford_Focus 22.11.19 11:38:19 (всего исправлений: 1)
а теперь 7 и чето не видно все еще в роадмапе
А как это связано с ucfirst? В питоне и руби якобы есть юникод, но тоже нет ucfirst. Или есть?
У них все от Component наследуется
И что? А в жабе всё наследуется от Object. Видимо жаба монолит.
Тот же app() вид сбоку. Ничего плохого не вижу.
Гораздо более явная, чем волшебные аннотации или параметры, которые непонятно, как и откуда пробрасываются.
Тестировать такой код становится сложнее
И в чём конкретно сложность?
В первом случае явно видно, что именно надо мокать при тестировании класса Some. Во втором этого не видно, пока не зайдешь в класс и не посмотришь конструктор
ЛОЛ, а что в первом случае знание параметров конструктора возникает телепатически? Как интересно ты вообще собираешься тестировать код, который ты даже не смотришь, и тем более не знаешь что он делает?
вы меня не поняли, но да ладно.
В отличие от декларативного DI. Который сразу отрезвит всё что надо? А как он это сделает пока исполнение не дойдёт до «глубины»? Мне кажется что декларативный даже раньше загнётся, т.к. ему, в отличие от простого DI-контейнера, нужно парсить файлы и заниматься рефлексией.
Жаль. Интересно что же ты имел в виду?
К тому же сервисный слой принято делать независимым, а с помощью app по всему коду, ты этого не получишь вообще никак. Компоненты проекта становится сильно связанными.
В случае с app, вызов которого можно запихать куда угодно и как угодно
Если ты хочешь возразить, что тут приходится полагаться на аккуратность программиста и что на это полагаться нельзя, то можешь сразу подумать о том, а что кроме аккуратности мешает указать 100500 ненужных параметров в конструкторе? Или что мешает указать более широкую зависимость, чем нужно? Да хотя бы указать параметром весь контейнер, и использовать его также как app()?
Компоненты проекта становится сильно связанными
Сильно — это сильно сказано, когда общая внешняя зависимость только одна. Зато она явная.
Пока нет. Использование параметров конструктора для DI имеет свои большие минусы. Например у тебя есть класс и 100 подклассов. Если тебе нужно добавить зависимость, то вместо того, чтобы просто в базовом классе в конструкторе дописать одну строчку, придётся в каждом из 100 классов править сигнатуру конструктора. Такая себе абстракция.
Пока нет. Использование параметров конструктора для DI имеет свои большие минусы. Например у тебя есть класс и 100 подклассов. Если тебе нужно добавить зависимость, то вместо того, чтобы просто в базовом классе в конструкторе дописать одну строчку, придётся в каждом из 100 классов править сигнатуру конструктора. Такая себе абстракция.
Он имеет ввиду, что если ты родительском классе, добавил, например Security, а в дочернем тебе захотелось EntityManager, но не хочется захламлять код перечислением всего, что притащил родительский класс, то всё очень плохо.
И приходится в родительский класс подтягивать Container, чтобы скрытно призвать все зависимости, что тебе нужны только в нём.
А, ну вообще да, есть такой момент)
Конкретно случая Макарова, то нужно было гуглить «symfony http basic auth» и обернуть в запуск только в dev, что он и сделал собственно, но шума столько-то поднял. Вижу он достаточно субъективен к остальным фреймворкам кроме своего, что также было заметно в недавнем видео о конференции в Сербии
Зачем в каждом из 100 дочерних классов править сигнатуру конструктора
Допустим есть такое
Анатолий Скорняков
Мечтатель, путешественник, программист 👨💻 🌏 ✈️ 📷
Новое в Symfony 5.0: Cтроковый компонент
Symfony 5.0 был выпущен 21 ноября 2019 года. В отличие от Symfony 4.0, он не меняет структуру каталогов полностью и не добавляет какой-либо принципиально новый способ разработки. Вместо этого Symfony 5 опирается на плечи Symfony 4 и предоставляет новые функции, облегчающие жизнь.
Согласно процессу выпуска Symfony, в Symfony 5.0 есть все новые функции, представленные в Symfony 4.4. Ознакомьтесь с новостями из серии Symfony 4.4, чтобы узнать обо всех этих замечательных функциях. Кроме того, Symfony 5.0 добавляет некоторые эксклюзивные функции, которые недоступны в Symfony 4.4. В этом блоге представлена одна из этих функций: новый компонент String.
Работать со строками сложно
Для таких языков, как английский, требуется очень ограниченный набор символов и символов для отображения любого содержимого. Тем не менее, другие языки требуют тысячи символов для отображения своего содержимого. Им нужны сложные стандарты кодирования, такие как Unicode, и вам приходится иметь дело с «кодовыми точками», «кластерами графем» и «байтами». Прочитайте документацию по компоненту String для ознакомления с этими терминами.
Компонент String абстрагирует эту сложность и предоставляет три простых класса для создания любых строк в соответствии с вашими потребностями:
Компонент также предоставляет некоторые функции быстрого доступа для быстрого создания строк:
Объектно-ориентированные строки
Создание строк – это только первый шаг. Этот компонент также предоставляет тщательно разработанный API для работы со строками объектно–ориентированным способом. Этот API может сделать ваш код намного более читабельным. Посмотрите, например, как проверить, заканчивается ли строка другой подстрокой:
Вы можете объединить все методы для выполнения расширенных преобразований строк (и с уверенностью, что они будут работать для любой строки на любом языке и в любом сценарии):
Если вы регулярно работаете со строками, компонент String – это воплощение вашей мечты. Компонент предоставляет десятки методов для решения всех ваших задач, связанных с поиском строк, заменой, добавлением, предварительным заполнением, заполнением, обрезкой, разделением, усечением и т. Д.
Некоторые из этих методов решают удивительно сложные проблемы. Представьте, что ваше приложение поддерживает разные языки, и вам нужно сравнивать без учета регистра. Применение strtolower() или mb_strtolower() перед выполнением сравнения не будет работать для некоторых языков. Почему? Поскольку языки определяют три регистра (нижний, верхний, заголовок), некоторые символы не имеют регистра, регистр зависит от языка и локали и т. д.
Найдите минутку, чтобы проверить ссылку на метод компонента String, и вы захотите сразу начать использовать его в своих проектах!
Струнный слаггер
Слаггеры являются популярной потребностью во многих приложениях. Они берут любую строку и преобразуют ее в другую строку, которую можно безопасно использовать в местах, где разрешены не все символы Юникода (URL-адреса, имена файлов или каталогов и т. д.)
Этот слаггер обеспечивает бесшовную интеграцию с платформой Symfony, поэтому вы можете автоматически связать его со своими службами, автоматически определить текущую локаль и т. д.
Интеграция с шаблонизатором Twig
Совместимость строковых компонентов
Компонент String был представлен как экспериментальная функция Symfony в Symfony 5.0. Это означает, что он достаточно стабилен, чтобы использовать его в работе, но его публичный API может немного измениться, прежде чем заморозить его в Symfony 5.1.
Экспериментальные функции не могут быть представлены в долгосрочной версии поддержки. Вот почему он был представлен в Symfony 5.0 вместо Symfony 4.4. В любом случае вам не нужно обновляться до Symfony 5, чтобы использовать этот компонент. Компонент String готов к использованию в любом приложении PHP 7.2.5 или более поздней версии.
Symfony 5 что нового
Symfony 5 was released on November 21st 2019. Update now to the best Symfony ever!
A Better Symfony
Symfony 5 continues the revolution started by Symfony 4 to build the best Symfony version ever released. Easier to learn, easier to configure and easier to install, deploy and master. Simple, powerful, amazing!
Automate everything
Symfony 5 integrates seamlessly with Symfony Flex to automate the most common tasks performed by applications. Forget about enabling bundles or creating their initial config: Symfony Flex does that for you.
The automation leverages the Symfony Recipes, which contain instructions to integrate hundreds of third-party bundles and packages into Symfony applications.
Faster and Leaner
The Symfony 5 source code has 37,000 less lines of code and runs 7% faster than the previous Symfony 4.x version. Upgrade now to make your applications fly.
New Components
Symfony 5 includes a new String component that provides an object-oriented API to work with UTF-8 Strings using bytes, code points and grapheme clusters. Need to create a «slug», trim content, replace text or do anything else on a string that could contain any characters? Do it quickly & safely with the String component.
Symfony 5 also includes a new Notifier component to create and send all kinds of notifications via SMS, email and chat services like Slack and Telegram.
To securely store «secrets», Symfony 5 has a secrets management system where sensitive production values can be safely encrypted and stored in version control. This works seamlessly with environment variables, allowing a consistent experience whether a value is «secret» or not.
Rock solid stability
The Symfony 5 framework is built with the latest version of the Symfony Components, the most popular set of libraries in PHP’s history. Battle tested in all popular PHP projects and with billions of downloads.
Smooth Upgrade
Thanks to our unrivaled Backward Compatibility Promise, upgrading your existing applications to Symfony 5 will be a smooth experience. First, upgrade to Symfony 4.4, which provides total compatibility with any Symfony 4.x version. Then fix any reported deprecation and you are ready to upgrade instantly to Symfony 5.
Learn from the Best
Symfony 5 releases together with a new book called Symfony 5: The Fast Track written by Symfony’s creator Fabien Potencier. Learn how to create modern web applications with Symfony and Redis, RabbitMQ, PostgreSQL, Docker, APIs, Single-Page Applications and more.
Как переиспользовать код с бандлами Symfony 5? Часть 7. Релизный цикл, установка и обновление
Поговорим о том, как прекратить копипастить между проектами и вынести код в переиспользуемый подключаемый бандл Symfony 5. Серия статей, обобщающих мой опыт работы с бандлами, проведет на практике от создания минимального бандла и рефакторинга демо-приложения, до тестов и релизного цикла бандла.
В предыдущих статьях серии мы вынесли переиспользуемый код в полноценный бандл, настроили и протестировали. В завершающей статье поговорим о жизненном цикле бандла: от установки до релизного цикла.
Если вы не последовательно выполняете туториал, то скачайте приложение из репозитория и переключитесь на ветку 6-testing.
Дисклеймер
Эта статья про бандлы будет наиболее «зыбкая», так как на некоторые вопросы, которые здесь поднимаются у меня пока что нет четкого ответа. Если вы знаете как сделать лучше, пожалуйста поделитесь в комментариях.
Установка бандла
Чтобы установить готовый бандл в проект, потребуется всем знакомая команда composer:
Эта команда выполнит необходимый минимум:
Однако более сложные бандлы могут требовать дополнительный действий по инициализации бандла. Вот только несколько вопросов, возникающих с уже знакомым нам демо-бандлом CalendarBundle :
Что можно сделать, чтобы облегчить жизнь пользователя и максимально автоматизировать процесс?
Пишите понятный и подробный README.md
Не все действия можно автоматизировать. Очевидная, но обязательная рекомендация: описывайте подробно инструкции по установке в README.md файле.
Указывайте конкретные команды, добавляйте примеры конфигов, фиксируйте подводные камни и проблемы с которыми сталкиваетесь в процессе разработки. Можно добавить в документацию бандла образцы файлов конфигурации или других файлов.
Документация незаменима при работе в команде, но пишите её даже если вы работаете над проектом один. Все это сэкономит ваше время и нервы, когда вы решите вернуться к разработке проекта после даже небольшого перерыва.
Автоматизация с Symfony Flex
Все это делает плагин composer Symfony Flex. Он позволяет определить так-называемый рецепт для установки бандла, в котором задаются необходимые для его инициализации действия. Для бандлов, у которых нет рецепта, используется авто-генерируемый рецепт. Он просто подключает бандл в проект и ничего более.
Но можем ли мы тоже воспользоваться магией Symfony Flex? В то время как для официальных и серьезных open-source проектов Flex прекрасно работает, для приватных проектов все не так гладко.
Дело в том, что рецепты по задумке должны храниться в отдельном от бандла репозитории. Их всего два: репозиторий для официальных бандлов Symfony и Contribution-репозиторий для всех остальных бандлов от сообщества Symfony. Contrib репозиторий публичный, принимает рецепты по заявкам и после модерации, что делает его бесполезными для частных проектов.
Для крупных компаний в бете фича, позволяющая создать приватный сервер рецептов. Вы можете попробовать создать свой по этим материалам:
Однако, есть несколько недостатков:
Все это делает Symfony Flex хорошим инструментом для официальной экосистемы Symfony и крупных open-source проектов Symfony-сообщества, но бесполезным для приватных бандлов на практике.
Использование CLI-команд Symfony
Итак, большую часть действий для запуска бандла нам придется выполнить вручную по инструкции из README.md
Но некоторые действия все же можно автоматизировать: мы можем создать обычную консольную команду внутри бандла.
Здесь мы проверяем, была ли выполнена инициализация ранее и определяем команду, которая создаст конфиг, если он еще не создан.
Такой подход имеет свои ограничения. Например конфиг не получиться создать, если бандл требует обязательных параметров в конфигурации. При инициализации команды бандл уже будет требовать наличия конфига и выдаст исключение.
Как вариант, можно написать не команду Symfony, а простой shell-script.
Обновление бандла
Как и любой программный продукт, бандл будет жить и развиваться. Поэтому о том, как будет организован процесс обновления нужно думать заранее.
Семантическое версионирование
Идея семантического версионирования в том, что вы определяете некий публичный контракт, гарантирующий неизменность интерфейса бандла. Далее с помощью специального формата версии вы указываете, есть ли в новой версии изменения, ломающие обратную совместимость и безопасно ли обновлять ваш пакет.
где каждая из переменных — неотрицательное натуральное число.
Выпуская новую версию увеличивают:
Менеджер зависимостей Composer работает с семантическим версионированием и позволяет гибко организовать процесс учета зависимостей, отслеживания их изменений и автоматического обновления пакетов, в которых нет обратно-несовместимых изменений.
Как выпустить новую версию бандла?
Версия бандла указывается в его composer.json :
Для локальной разработки этого будет достаточно, но обычно Composer загружает пакет из удаленного git-репозитория. Чтобы понять, где искать нужную версию каждый релиз должен быть помечен тегом в формате соответствующей версии. Например:
После того как вы пушнете обновленный composer.json и новый тег в удаленный репозиторий — composer сможет обнаружить новую версию.
Какую версию указывать для нового бандла?
В composer.json приложения-хоста мы добавили:
Знак ^ перед версией разрешает composer загружать все версии бандла, не ломающие обратную совместимость:
Как проверить доступность новых обновлений?
Увеличим в bundles/CalendarBundle/composer.json патч версию:
Команда выведет список бандлов для которых есть обновления. Левая версия — текущая, правая — последняя доступная. Композер выделяет красным цветом новую версию, которую можно безопасно загрузить без нарушений обратной совместимости.
Теперь увеличим минорную версию бандла:
Теперь Composer подсветил новую версию желтым. Это означает, что возможны изменения обратной совместимости. При обновлении composer не загрузит эту версию до тех пор, пока вы вручную не поднимите её в секции require composer.json приложения-хоста.
Как обновлять?
Команда загрузит все безопасные обновления.
Учет изменений в CHANGELOG.md
С развитием проекта, в вашем бандле неминуемо будут появляться изменения, ломающие обратную совместимость. Такие изменения необходимо отслеживать и документировать. Еще лучше отслеживать все основные изменения. Для этого используется файл CHANGELOG.md
Представьте, что ваш бандл используется в двух проектах. Вы активно работаете над первым, а второй пока простаивает. Во время работы вы расширили функциональность своего бандла, — стали появляться изменения, ломающие обратную совместимость.
Спустя несколько мажорных версий (или минорных если вы «в стадии активной разработки» и еще версионируете с 0.X.X ) вам необходимо продолжить работу над вторым проектом. Чтобы обновиться придется пофиксить все изменения, ломающие обратную совместимость. Но без CHANGELOG.md — эта задача если и не невозможна, то крайне затруднительна. Проще будет удалить и начать сначала!
Если же вы ведете CHANGElOG.md, то в нем вы можете указать основные изменения и необходимые для миграции действия.
Я веду простой лог примерно в таком формате:
Проблема миграций
Использование размеченных Doctrine сущностей создает проблемы с миграциями.
Миграции специфичны для конкретного окружения. Они должны генерироваться и храниться в конкретном проекте, но не в бандле. Если изменения в базе достаточно просты — проблем может не возникнуть.
Но если при миграции вам нужно сохранить и каким-то особым образом преобразовать уже имеющиеся данные возникнет проблема: где-то нужно хранить логику этих преобразований.
Если в обычном приложении можно модифицировать миграцию и добавить туда нужные SQL запросы для преобразования, то что делать с бандлом, миграции для которого генерирует пользователь?
Этот вопрос пока остается открытым.
Как возможный вариант можно использовать команды, для того, чтобы хранить логику преобразований между отдельными версиями и указывать на необходимость запуска этих команд в инструкциях по обновлению.
Резюме
В заключительной статье серии мы поговорили о некоторых практических советах как организовать первичную установку, дальнейшую работу над бандлом и выпуск новых релизов. Многие вопросы в разработке бандлов остаются открытыми — предлагаю вам поделиться своим опытом в комментариях.
Финальную версию кода для этой статьи вы найдете в ветке 7-support.