> в каком каталое > облака

Все так

Иначе var/storage какой-нибудь

С проверками. Тогда этот вариант, спасибо!

Все так

Все гвозди своим микроскопом перегнул, ну.

Почему? Предлагаешь локально сейвить документы? Рано или поздно прийдут к s3

То есть контроллер вызывает сервис-респондер? Этакий самообман на тему анемичности контроллера.

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

Самое лучшее применение "респондеров", которое я видел - это берем короче, забиваем на сериалайзеры и делаем response dto ручками.

Действительно. Нафига группы, кастомные нормалайзеры. Можно же свое скидать!

на респонсе нафиг эти seriliazer не нужны

:D

а вот на реквесте они удобны

Ты сериалайзинг с десериалайзингом не путай

ну серализер же работает в 2 стророны

так что ничего не спутал

и на респонс отлично сериалайзер работает

причем можно автоматизировать, твой контроллер будет принимать уже валидный объект ДТО и отдавать тоже объект ДТО

и на респонс отлично сериалайзер работает

и зачем этот оверхед?

в чем проблема отдать new JsonResponse($view) ?

а вот если xml отдавать, то тут да без serializer никак

в чем проблема отдать new JsonResponse($view) ?

А можно короче отдавать json(тут гора всяких объектов) и не парить себе до этого голову. Сериализуется на отличненько.

А можно короче отдавать json(тут гора всяких объектов) и не парить себе до этого голову. Сериализуется на отличненько.

можешь и функцию описать, тока зачем

Если сразу json отдавать то если потом захочется сделать повторное использование то придётся рефакторить, заносить код в какой-то метод, который возвращает не-json.

что ты хочешь повторно использовать?

контроллер?

То что контроллер получает

$view = $handler->ask(...)

return new JsonReponse($view);

Вьюхи какие то.

объектит или коллекция пуская будет

return new JsonReponse($view);

а где эти: $view = $handler->ask(...) и return new JsonReponse($view); должны находится?

а где эти: $view = $handler->ask(...) и return new JsonReponse($view); должны находится?

ну наверное контроллер?

и зачем этот оверхед?

Какой еще оверхед? Это уменьшение болерплейт кода, нафига писать одно и тоже, когда можно автоматизировать

Что-то мне подсказывает что вьюхи это костыльный сериалайзер

Я размечаю сущность группами. Например типа admin. И потом везде в контексте сообщаю что нужно слепить представление именно с такими пропами.

Какой еще оверхед? Это уменьшение болерплейт кода, нафига писать одно и тоже, когда можно автоматизировать

твой объект должен пройти все нормализеры и пропертиакцесооры и плюс еще рефлексия

нихуя себе блять нету оверехеда

А, вы таки на калькуляторах сервитесь. Мое сожаление

пфф, запрос в БД больше жрет

Я размечаю сущность группами. Например типа admin. И потом везде в контексте сообщаю что нужно слепить представление именно с такими пропами.

это магия

которую сложно контроллировать еще

Хренагия. Не нравится магия автовайришь нормалайзер и руками его вызываешь

легче описать вьюшку/дтошку

и сразу видно что уходит

Уходит мое время, когда я вижу код с респондерами 😂

ну реально, это надо держать в голове, что при какой группе что вылетит

зачем это дрочь не понятно

> держать в голове. Берёшь короче группы константами хранишь. И передаешь в контекст тоже ими. И вуа ля. Открывая сущность видно что где вылетит.

ну то есть серавно в голове держать

Уходит мое время, когда я вижу код с респондерами 😂

А что за респондеры? Можно пример?

На вход что то, на выход дто

> держать в голове. Берёшь короче группы константами хранишь. И передаешь в контекст тоже ими. И вуа ля. Открывая сущность видно что где вылетит.

и второй же вопрос. Зачем мне сущность? мне нужны n полей, будешь доставать полностью сущность?и потом вешать группы

О нет. Партиалы всё-таки отменили?

О нет. Партиалы всё-таки отменили?

ага в помойку

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

ага в помойку

Ну. Когда посложнее ага. Выбираешь сразу в дто. И сериалайхеру кормишь.

Где в этой схеме твой костыль респондер?

а причем здесь вьюха? собираю resultSetMapping

и

new Foo(...$results)

Покежь коротенький пример своих респондеров. Шоб я прям передумал и согласился, что это круто!

вьюхи чтоле

class с readonly полями

все больше там ничего нету

Что обьектит?

м?

Кто нить писал мультиязычные приложения? Вопрос такой, как резолвить выбор языка юзером? в плане. можно конечно написать класс, который это делает, но не охота тащить эту зависимость везде, где надо языки юзать. Думаю сделать функцию, но опять же, где её хранить? Какие еще варианты есть?

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

В ивент листенере

А, вы таки на калькуляторах сервитесь. Мое сожаление

На больших респонсах сериалайзер сильно жрет,банально проходка. Как то перепутал, засунул массив в сериалайзер вместо просто в jsonRespose - разница в разы шла.

Кто нить писал мультиязычные приложения? Вопрос такой, как резолвить выбор языка юзером? в плане. можно конечно написать класс, который это делает, но не охота тащить эту зависимость везде, где надо языки юзать. Думаю сделать функцию, но опять же, где её хранить? Какие еще варианты есть?

Проголосую за зависимость.

На больших респонсах сериалайзер сильно жрет,банально проходка. Как то перепутал, засунул массив в сериалайзер вместо просто в jsonRespose - разница в разы шла.

На БОЛЬШИХ респонсах надо отказываться от гидраций, сериалайзинга и прочего. Но это ведь не значит, что везде так надо.

На БОЛЬШИХ респонсах надо отказываться от гидраций, сериалайзинга и прочего. Но это ведь не значит, что везде так надо.

Ну понятно что живут проекты и на сериалайзере с лэзи лоадом с 100 запросами в БД за раз и норм. Но решение не совсем удачное. Где нить мб для готовых решений, чтобы быстренько изменить респонс, да. А так... путь близкий в никуда, который надо потом менять.

Ну где надо поменяем, когда начнутся проблемы

Не вижу вообще проблем

Ага. Частая проблема. Стелим солому там, где не надо.

А кто как делит разные api в Symfony? Например frontend-api, service-api, backend-api, у которых как бы единая база данных, как и кодовая база. Сейчас просто разделяю на уровне routes, прописывая разные папки контроллеров и назначаю хосты., каждому по своему firewall, но может я совсем что-то не то делаю?)

А зачем разделение? Что за проблему решает разделение

Ну где надо поменяем, когда начнутся проблемы

А какой профит вообще изначальный? Пишутся отдельные классы нормалайзеры, настраиваются группы разные, пишутся запросы с отдельным егар лоадингом, связываются сущности чисто для рида. Я просто сколько не сталкивался с номалайзерами, которые наичнали писать до меня - обычно это приносит как проблемы с производительностью, так и объем работы +- такой же.

Ага. Частая проблема. Стелим солому там, где не надо.

Yagni

А зачем разделение? Что за проблему решает разделение

Разное назначение, frontend доступен всем, service для межсервисного взаимодействия, backend для некой админки, и так проще разграничивать функционал