так просто не получается, и не пойму почему

может в конфиге что то дописывать ?

ошибка есть какая-то?

ну и в качестве теории. бандл, где описывается сервис, должен регистрироваться раньше, чем бандл, в конфигах которого ты его инжектишь.

так просто не получается, и не пойму почему

Дмитрий, ну если Вы задаете вопрос, то почему не предоставить код\ошибку\стектрейс?

сейчас, минутку

Поддерживаю. Надо золотое правило ввести. Бесполезно писать просто "не работает", нужна инфа по коду, который "работает не так" и какие-то симптомы, как было выяснено, что он работает "не так". Иначе каждый раз libastral.so подгружать накладно.

class:"RuntimeException" "Controller "ApiBundle\Controller\ApiModeratorController::updateStatusAction()" requires that you provide a value for the "$manager" argument. Either the argument is nullable and no null value has been provided, no default value has been provided or because there is a non optional argument after this one."

Инжекти явно в контроллер

Тут с автовайром хрень какая-то

class:"RuntimeException" "Controller "ApiBundle\Controller\ApiModeratorController::updateStatusAction()" requires that you provide a value for the "$manager" argument. Either the argument is nullable and no null value has been provided, no default value has been provided or because there is a non optional argument after this one."

ты его экстендишь от фосовского? как в фосе сделана иньекция - через JMS DI Extra или через controller arguments?

короче тебе нужно контроллер как сервис зарегать

+ https://symfony.com/doc/current/controller.html#controller-accessing-services

экстендю от фосовского

Инжекти явно в контроллер

если инжектю в контроллер то "Resources are not supported in serialized data. Path: Monolog\Handler\StreamHandler -> Symfony\Bridge\Monolog\Logger -> Symfony\Component\Cache\Adapter\PhpFilesAdapter -> Symfony\Component\Cache\Adapter\TraceableAdapter -> Symfony\Component\Cache\Adapter\PhpArrayAdapter -> Symfony\Component\Cache\DoctrineProvider -> Doctrine\Common\Annotations\CachedReader -> Doctrine\ODM\MongoDB\Mapping\Driver\AnnotationDriver -> Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain -> Doctrine\ODM\MongoDB\Configuration -> Doctrine\MongoDB\Connection -> Doctrine\ODM\MongoDB\DocumentManager -> AppBundle\Service\DocManager"

Как в симфони принято сетить данные из массива в обьекты, через гидратор ?

сериализатор/форма

как я успел понять, конечно. Не особо много юзаю симфу

что за сериалайзер ?

Как в симфони принято сетить данные из массива в обьекты, через гидратор ?

гидратор это понятие из зенда ?

dataMapper

propertyAccessor

первый пишется в помощью второго(это компонента)

datamapper это часть формы, которая занимается маппингом

гидратор это другое

Я не знаю откуда паттерн гидратор, видел его использование для сета данных сущностям

чувак, у тебя есть просто массив данных, propertyAccessor сделает то что тебе надо

надйет пропертю и вставит значение через сеттер если такой есть

я написал что-то похожее для маппинга респонса апи на дтошки, описывал путь в конфиге и получал на выходе дто с данными

я написал что-то похожее для маппинга респонса апи на дтошки, описывал путь в конфиге и получал на выходе дто с данными

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

да интересно, конфиг как используется

Как в симфони принято сетить данные из массива в обьекты, через гидратор ?

https://symfony.com/doc/current/components/serializer.html

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

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

А чем не устроил serializer + ObjectNormalizer?

Хотя да, все равно пришлось бы писать кастомные нормалайзеры

А для конвертации одних объектов в другие (DTO => Entity, например) какой подход рекомендуется?

апдейт в энтити написать имхо

который будет хавать в себя дто и че-то там внутри делать

Entity::createFromDto(Dto $dto);

А для конвертации одних объектов в другие (DTO => Entity, например) какой подход рекомендуется?

ну сериалайзер же

например jms/serializer

например jms/serializer

медленно

на пыхе 7 проблем нет вообще нисколько

медленно

symfony/serializer + свои нормалайзеры

можно юзать свой/симфони сериалайзер

Entity::createFromDto(Dto $dto);

рак

ахахах

есть такое

С какой это стати?

например jms/serializer

кхм, он же десериалузет из сериализованных форматов, или я чего-то не знаю? делать DTO => json => Entity звучит как-то дико.

Лучше неявное?

Лучше неявное?

неявное что?)

createFromDTO - рак

кхм, он же десериалузет из сериализованных форматов, или я чего-то не знаю? делать DTO => json => Entity звучит как-то дико.

это как в джс делают копию обьекта Json.Parse(Json.stringify(lol))

неявное что?)

Неявное serializer->serialize ()

кхм, он же десериалузет из сериализованных форматов, или я чего-то не знаю? делать DTO => json => Entity звучит как-то дико.

да, jms тоже рак, symfony serializer более-менее... но только если ты им делаешь dto)

кхм, он же десериалузет из сериализованных форматов, или я чего-то не знаю? делать DTO => json => Entity звучит как-то дико.

у вас явная необходимость в dto?

Чем нормально контролировать ассайн?

да, jms тоже рак, symfony serializer более-менее... но только если ты им делаешь dto)

пруф

пруф

пруф на что? что не очень хорошая идея сразу пихать данные в сущности?

ты определись что тебе надо - гидрация данных или засэтать что-то

на jms - рак

?

на jms - рак

рак причем с метастазами. Концептуально это очень кривая штука

createFromDTO - рак

таки как тогда?

ERROR: S client not available

подход симфони с промежуточным этапом нормализации/денормализации намного лучше

у вас явная необходимость в dto?

интеграция с внешними сервисами, которые требуют одни и те же данные, но по разному их обзывают + их надо сохранять в базу. итого имеем получение одного DTO от одного сервиса, конвертацию в Entity для сохранения и конвертацию в другое DTO для отправки в другой сервис. сейчас есть классы-маперы, которые в тупую делают полотно get => set на каждое свойство. вот спрашиваю можно ли от этого как-то красиво уйти.

таки как тогда?

смотря что сделать надо) приведи юзкейс когда ты хочешь сделать createFromDTO и откуда этот dto у тебя возьмется

ну у него есть форма data_class -> someDto

интеграция с внешними сервисами, которые требуют одни и те же данные, но по разному их обзывают + их надо сохранять в базу. итого имеем получение одного DTO от одного сервиса, конвертацию в Entity для сохранения и конвертацию в другое DTO для отправки в другой сервис. сейчас есть классы-маперы, которые в тупую делают полотно get => set на каждое свойство. вот спрашиваю можно ли от этого как-то красиво уйти.

взять готовый мэппер разве что, который будет это делать менее явно.

и он хочет с дто получить уже сущность

интеграция с внешними сервисами, которые требуют одни и те же данные, но по разному их обзывают + их надо сохранять в базу. итого имеем получение одного DTO от одного сервиса, конвертацию в Entity для сохранения и конвертацию в другое DTO для отправки в другой сервис. сейчас есть классы-маперы, которые в тупую делают полотно get => set на каждое свойство. вот спрашиваю можно ли от этого как-то красиво уйти.

Поддерживаю

и он хочет с дто получить уже сущность

что из себя представляет dto - там вообще весь новый стэйт сущности? и надо тупо засэтать?

смотря что сделать надо) приведи юзкейс когда ты хочешь сделать createFromDTO и откуда этот dto у тебя возьмется

к примеру есть симфони-форма, надо DTO, который в нее передается создать Entity

что из себя представляет dto - там вообще весь новый стэйт сущности? и надо тупо засэтать?

тупо засетать как я понял

тупо засетать как я понял

какой смысл тогда делать dto

ну то есть это проблема несколько другого уровня

взять готовый мэппер разве что, который будет это делать менее явно.

например какой? ну или хотя бы в какую сторону копать?

шоб firstName, lastName можно было обозвать name

ну чет аткое

если у тебя есть сущность и ты хочешь все поля в ней обновить - возможно тебе стоит сделать новую сущность

хз, не юзаю

Так пусть маппер создаёт дто, оно валидируется, и ассайнится в сущность. Иначе мы получаем хрень с невалидной сущностью после маппера

ну чет аткое

VO

И это рак

ну как я понял с описания

обычно такое нормально делается в форме

и дто не надо

короч если тебе нужен createFromDTO то у тебя сущность зависит от DTO что я считаю категорически не правильным

обычно такое нормально делается в форме

Нифига не согласен

еп

Нифига не согласен

скажи кейс который я не смогу сделать в форме

обычно такое нормально делается в форме

сущности в формы пихать еще больший рак)))

Динамически доступные поля на основе значений выше

сущности в формы пихать еще больший рак)))

И я об этом

мне больше билдеры нравятся нежели DTO, позволяют чуть лучше разделить ответственность и при этом примерно то же самое

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