я помню, что всё было настолько незначительно, что в итоге на слим не пересел, остался на симфе.

и чем же? Он же такой же по размеру как симфа дефолтная, но медленнее просто

Ну например там есть нормальный подход с миддлеварами, а не листенеры, хотя бы в этом плюс

Ну например там есть нормальный подход с миддлеварами, а не листенеры, хотя бы в этом плюс

а что это дает?

а что это дает?

Просто удобство

ХЗ с лисерами тоже норм

Ну например там есть нормальный подход с миддлеварами, а не листенеры, хотя бы в этом плюс

Ну ,"нормально" - это понятие размытое слишком

Вот у тебя, допустим, сервер сайт эвентс, один запрос и много ответов

Как это через миддлвари сделать?

Хотя можно один ответ, конечно, и даже наверное лучше

Всё же миддлвари синхронные, один запрос - один ответ. Это удобно и подходит для 99% случаев

Но когда параллелить придётся или на один запрос не один ответ - тогда веселуха

С другой стороны http psr помойка сраная, так что всё что угодно лучше, нежели psr)

С другой стороны http psr помойка сраная, так что всё что угодно лучше, нежели psr)

У симфони код посмотри, намного лучше разве?

Я не про код, я про архитектуру и удобство

Архитектурно хттп кернел симфы лучше

По крайней мере там квери параметры в одном месте, а не в двух разных)

И хедеры в одном месте, а не в 3х разных местах

Ну у мидваров тоже есть плюсы. Их можно на определённый контекст навесить и всё. Я щас работаю с легаси монолитом (ещё на бандлах) решил бахнуть http листенер для проверки сигнатуры запроса. Ну и ясен красен он работает на всех бандлах, во всех запросах. Приходится изголяться с доп проверками внутри листенера

А миддлввру на группу роутов кинул и в путь. Не страшно

Ну у мидваров тоже есть плюсы. Их можно на определённый контекст навесить и всё. Я щас работаю с легаси монолитом (ещё на бандлах) решил бахнуть http листенер для проверки сигнатуры запроса. Ну и ясен красен он работает на всех бандлах, во всех запросах. Приходится изголяться с доп проверками внутри листенера

так а там же можно решить 1 ифом по имени роута/ов

так а там же можно решить 1 ифом по имени роута/ов

Ну вообще это можно решить атрибутом на контроллере На прошлой работе я так и сделал, но на новой в такой отрыв мне пока не дадут уйти, так что да. Иф который срабатывает каждый запрос

так этот иф ничего не стои же, там затраты на эту проверку даже не копейки по времени

Если сайт по продажи памперсов - то да.

Или если 100 эндпоинтов нужны без подписи, а один-два с подписью

Ну вообще это можно решить атрибутом на контроллере На прошлой работе я так и сделал, но на новой в такой отрыв мне пока не дадут уйти, так что да. Иф который срабатывает каждый запрос

или на группе роутов, а не на конкретном)

Добрый день. Кто-нибудь может подсказать, как настроить normalize, чтобы он не менял регистр в строке?

Добрый день. Кто-нибудь может подсказать, как настроить normalize, чтобы он не менял регистр в строке?

написать кастомный

Как пишете логику отдачи повторяющихся структур данных во многих запросах. Например json объект профиля нужно отдавать в едином виде во многих эндпоинтах, так как на клиенте эта структура типизирована через TS. Я создал отдельный хелпер класс с методом prepareProfile в который я передаю интерфейс юзера и он из этого составляет массив с полями который прописаны на клиенте, внутри prepareProfile также идет обращение к другим таким же методам prepare например корзины или других таких данных который тоже типизированы на клиенте и со всех всех эндпоинтах нужно отдавать в одном виде чтобы название полей и их типы данных совпадали. Вопросу к тому что нормально ли так делать, может есть более приемлемый способ

написать кастомный

Спасибо, я понадеялся, что есть более простой способ)

Спасибо, я понадеялся, что есть более простой способ)

Возможно поможет этот раздел https://symfony.com/doc/current/components/serializer.html#converting-property-names-when-serializing-and-deserializing

А так же посмотреть текущие настройки

Как пишете логику отдачи повторяющихся структур данных во многих запросах. Например json объект профиля нужно отдавать в едином виде во многих эндпоинтах, так как на клиенте эта структура типизирована через TS. Я создал отдельный хелпер класс с методом prepareProfile в который я передаю интерфейс юзера и он из этого составляет массив с полями который прописаны на клиенте, внутри prepareProfile также идет обращение к другим таким же методам prepare например корзины или других таких данных который тоже типизированы на клиенте и со всех всех эндпоинтах нужно отдавать в одном виде чтобы название полей и их типы данных совпадали. Вопросу к тому что нормально ли так делать, может есть более приемлемый способ

Ну в целом норм, поосто есть ещё проблема что в одном месте нужно больше полей, в другом меньше, но фигачить это через сериалайзер не хочется - опасно Я обычно создаю dto для респонса, внутри этой дто есть несколько конструкотров (что бы из разных контекстов было бы удобнее мапить) Ну и при надобности дто знает про свои вложенные поддтошки и пропихивает контекст в них

Ну в целом норм, поосто есть ещё проблема что в одном месте нужно больше полей, в другом меньше, но фигачить это через сериалайзер не хочется - опасно Я обычно создаю dto для респонса, внутри этой дто есть несколько конструкотров (что бы из разных контекстов было бы удобнее мапить) Ну и при надобности дто знает про свои вложенные поддтошки и пропихивает контекст в них

👍

Но нащёт сериализатора. С другой стороны есть тесты, так что он тоже норм. Но управлять отрисовкой через слова в атрибутах, кажется странным

А ещё, что бы не парится с вложенностью и контекстной отрисовкой, можно глянуть в сторону json api Не надо его полностью реализовывать, но можно посмотреть на те принципы, которыми эта спека пользуется для респонсов

Как пишете логику отдачи повторяющихся структур данных во многих запросах. Например json объект профиля нужно отдавать в едином виде во многих эндпоинтах, так как на клиенте эта структура типизирована через TS. Я создал отдельный хелпер класс с методом prepareProfile в который я передаю интерфейс юзера и он из этого составляет массив с полями который прописаны на клиенте, внутри prepareProfile также идет обращение к другим таким же методам prepare например корзины или других таких данных который тоже типизированы на клиенте и со всех всех эндпоинтах нужно отдавать в одном виде чтобы название полей и их типы данных совпадали. Вопросу к тому что нормально ли так делать, может есть более приемлемый способ

на этом месте можно забивать читать

на этом месте можно забивать читать

Почему?

Как пишете логику отдачи повторяющихся структур данных во многих запросах. Например json объект профиля нужно отдавать в едином виде во многих эндпоинтах, так как на клиенте эта структура типизирована через TS. Я создал отдельный хелпер класс с методом prepareProfile в который я передаю интерфейс юзера и он из этого составляет массив с полями который прописаны на клиенте, внутри prepareProfile также идет обращение к другим таким же методам prepare например корзины или других таких данных который тоже типизированы на клиенте и со всех всех эндпоинтах нужно отдавать в одном виде чтобы название полей и их типы данных совпадали. Вопросу к тому что нормально ли так делать, может есть более приемлемый способ

Идея хороша, я использую паттерн - трансформер, чтобы одни данные превращать в другие Например как здесь, интерфейс симфонии необязательно использовать https://symfony.com/doc/current/form/data_transformers.html

Добрый день. Кто-нибудь может подсказать, как настроить normalize, чтобы он не менял регистр в строке?

Я бы рекомендовал отказаться от symfony serializer в пользу JMS

1) Он гибче 2) Он удобнее 3) Он стабильнее (на порядки меньше багов) 4) Он лучше написан 5) И на порядки быстрее (я сильно старался оптимизить свой сериалайзер, но так и не удалось его догнать, см. бенчи https://github.com/php-type-language/mapper?tab=readme-ov-file#denormalization)

1) Он гибче 2) Он удобнее 3) Он стабильнее (на порядки меньше багов) 4) Он лучше написан 5) И на порядки быстрее (я сильно старался оптимизить свой сериалайзер, но так и не удалось его догнать, см. бенчи https://github.com/php-type-language/mapper?tab=readme-ov-file#denormalization)

Какие баги есть в сериалайзере симфы?

Какие баги есть в сериалайзере симфы?

ну из последнего с чем сталкивался - нормализация, где есть поля, содержащие квадратные скобки

Он это как property path рассматривал с какого-то перепуга

Ну или вот такое тоже весело: $serializer = new \Symfony\Component\Serializer\Serializer([ new \Symfony\Component\Serializer\Normalizer\ObjectNormalizer(), ]); class Example { public function __construct( public string $value, ) {} } $result = $serializer->denormalize(['value' => [1, 2, 3]], Example::class);

PHP Fatal error: Uncaught TypeError: Example::__construct(): Argument #1 ($value) must be of type string, array given

А ожидаю я что-то вроде такого (это пример из другого сериалайзера): Passed value in "value" of Example{value: string} must be of type string, but [1, 2, 3] given at $.value

А как тебе такое? class Example { public function __construct( public string $value, ) {} } $result = $serializer->denormalize([ 'value' => 'asd', 'value.0' => [1, 2, 3], ], Example::class); >> PHP Fatal error: Uncaught Symfony\Component\PropertyAccess\Exception\UnexpectedTypeException: PropertyAccessor requires a graph of objects or arrays to operate on, but it found type "string" while trying to traverse path "value.0" at property "0". in /home/serafim/local/type-language/libs/mapper/bench/vendor/symfony/property-access/PropertyAccessor.php:328

Мне стоит объяснять почему это может быть потенциально фатальной уязвимостью, учитывая как любят маппить типы на энтити? Т.к. денормалайзер имеет прямой доступ к любому вложенному объекту, используя property path

Мне стоит объяснять почему это может быть потенциально фатальной уязвимостью, учитывая как любят маппить типы на энтити? Т.к. денормалайзер имеет прямой доступ к любому вложенному объекту, используя property path

Да, сериалайзер это самый зашкварный пакет у симфони

Зpaвcтвyйтe.Предлагаю удаленная работу Oт 200 $ в дeнь. Количество мест ограничено Зa пoдpoбнocтями пиши плюс в лс

Зpaвcтвyйтe.Предлагаю удаленная работу Oт 200 $ в дeнь. Количество мест ограничено Зa пoдpoбнocтями пиши плюс в лс

оп - ретраи пошли)

PHP Fatal error: Uncaught TypeError: Example::__construct(): Argument #1 ($value) must be of type string, array given

Это вроде этим решается https://symfony.com/doc/current/components/serializer.html#collecting-type-errors-while-denormalizing

Но там проблема с неймингом вроде как. Но не 500 ошибка

Да, сериалайзер это самый зашкварный пакет у симфони

не самый, просто один из)

Зpaвcтвyйтe.Предлагаю удаленная работу Oт 200 $ в дeнь. Количество мест ограничено Зa пoдpoбнocтями пиши плюс в лс

Это вроде этим решается https://symfony.com/doc/current/components/serializer.html#collecting-type-errors-while-denormalizing

ничосе, они починили

ничосе, они починили

Это не точно, но мне кажется примерно каждые полгода это обсуждается тобой))

Это не точно, но мне кажется примерно каждые полгода это обсуждается тобой))

Не, вот это не обсуждали

Мы обсуждаем раз в пол года сериалайзер. Я его пробую, нахожу говно и выкидываю. Потом ты говоришь что починили, я радуюсь, потом нахожу новое

И так по-кругу)

))))

Мы обсуждаем раз в пол года сериалайзер. Я его пробую, нахожу говно и выкидываю. Потом ты говоришь что починили, я радуюсь, потом нахожу новое

а че вы просто не юзаете сериалазер ?

или какие альтернативы ? json_decode ?

а че вы просто не юзаете сериалазер ?

Так есть на проекте и там километр костылей просто чтоб он работал

Не, вот это не обсуждали

Ну просто эта штука уже с 5 версии, а вопрос поднимали где то недавно

Так есть на проекте и там километр костылей просто чтоб он работал

*в одном месте остался)

а так-то везде JMS уже

у JMS только одна проблема - требуется для array типы явно прописывать

Так есть на проекте и там километр костылей просто чтоб он работал

В целом вообще не сталкиаюсь с проблемами сериалайзера, причем из коробки

Почти на всех проектах. MapRequest симфы -тоже на нем

Возможно я просто не извращаюсь с контрактами апи))

ну в моём случае это сообщение + path

Единственное что - не юзаю конструкторы на дто, потому что он плохо ошибки пишет, как раз в твоем первом примере

не, они это починили)))

1) Он гибче 2) Он удобнее 3) Он стабильнее (на порядки меньше багов) 4) Он лучше написан 5) И на порядки быстрее (я сильно старался оптимизить свой сериалайзер, но так и не удалось его догнать, см. бенчи https://github.com/php-type-language/mapper?tab=readme-ov-file#denormalization)

на самом деле производительность serialazer symfony оставляет желать лучшего, буквально пару месяцев назад они добавили кэширование повторяющихся объектов - но вот тоже хз так а че там,в вашем решение, кэширование есть ? относительно просто перейти на него например в apiplatform или мы заебемся ?

года 3 назад, да, там в зависимости от того какой у тебя конструктор - совершенно разное поеведение

года 3 назад, да, там в зависимости от того какой у тебя конструктор - совершенно разное поеведение

Да не, я на 6.4 пробовал

Но уже не помню что

Не критично было, но меня не устроило