Так не сказано же :)

Кстати, можно еще указать Accessor

Тогда он будет пытаться из геттера достать

все получилось, спасибо

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

вроде как все советуют его юзать а не jms

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

ну можно же свой велосипед накодить с аннотациями?

мне щас пока такой подход видится проще - но я тока изучаю сф

с JMS просидел пару часов - чтобы разобраться как сделать чтобы свойства у объектов были в camelCase

Ну не знаю что там пару часов делать, гуглится все быстро

Присоединяюсь к просьбе о внятном туториале по встроенному сериалайзеру.

Чето не получается нормализация. Ругается на цикличные зависимости. Читал в доке как это обходить но так и не получилось реализовать

Привет. А в чем вообще сокральный смысл делать вот так services: my_entity_repository: class: AppBundle\Repository\MyEntityRepository factory: ["@doctrine", getRepository] arguments: - %entity.my_entity% ?? Почему просто не сделать свой репозиторий и инжектить туда что захочешь? Оттуда же можно получить доктироновский репозиторий если нужно.

ну так будут доступны методы из базового репоса, плюс разные плюшки типа createQueryBuilder, _entityName и тд

но лучше не наследоваться)

но лучше не наследоваться)

Так зачем наследоваться. Можно же в конструкторе сделать вот так $this->doctrineRepository = $em->getRepository(Entity::class); если нужно пользоваться

не, не стоит. тесты писать потом на это дело не очень

не, не стоит. тесты писать потом на это дело не очень

ну репозитории ты юнитами не покроешь

ну репозитории ты юнитами не покроешь

я про $this->doctrineRepository = $em->getRepository(Entity::class); в конструкторе

все зависимости ты указываешь как и в сервисах через конструктор автовайринг работает, контроллеры регистрируются как сервисы и что самое главное фишки типа $this->render() которые требуют контейнера работают, потому что симфони пихает их через ServiceSubscriberInterface

@Enleur а можешь пример контроллера гистом кинуть?

я про $this->doctrineRepository = $em->getRepository(Entity::class); в конструкторе

я так делаю в своих репозиториях и спокойно себя чувствую

@Enleur а можешь пример контроллера гистом кинуть?

чти доки к symfony 3.3

чти доки к symfony 3.3

Читал, но вот момент с ServiceSubscriberInterface остался неясен. Вообще интересны успешные кейсы с контроллерами как сервисами, есть ли реальный профит в этом помимо морального удовлетворения? Тестируемость теоретически намного лучше, но на контроллеры редко пишутся юниттесты

смотря что в контроллерах

я б тоже глянул как другие делают ибо то как делаю я мне не нравится

у нас __construct + __invoke и AppBundle\Action\: resource: '../../../src/AppBundle/Action' tags: ['controller.service_arguments']

экшены

Вопрос по Доктрине. Как написать условие запроса - если поле таблицы это айдишник другой сущности (@ORM\ManyToOne)? Criteria бы идеально использовать - но там типа через точку писать нельзя, может я что-то не докопал в доке/гугле? Писать именно запросом как бэ не хочется...

@Enleur а можешь пример контроллера гистом кинуть?

да, завтра сделаю если время будет. на эту тему доков не много на самом деле

Привет. Вот такая трабла. Не знаю как лучше сделать. Например есть модели с такой иерархией. Catalog (1)-> (M)Group (1) ->(M) Post. И находясь в каталоге необходимо фильтровать их по филтрам которые относятся к постам. То есть 3 join минимум будет. В итоге в выборка должна иметь такую структуру : `[ [ 'id' => 1, 'name' => 'catalog1', 'groups' => [ [ 'id' => 1, 'name' => 'group1', 'postCount' => 10 ], [ 'id' => 2, 'name' => 'group2', 'postCount' => 24 ], ] ], [ 'id' => 2, 'name' => 'catalog2', 'groups' => [ [ 'id' => 3, 'name' => 'group4', 'postCount' => 102 ], [ 'id' => 4, 'name' => 'group5', 'postCount' => 241 ], ] ] ]` То есть выдаю каталоги, в которых группы, а в группах Count (post) для нее.

так а в чем трабла? не умеешь в SQL?

или есть какие-то конкретные опасения?

так а в чем трабла? не умеешь в SQL?

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

что будет эффективнее, 3+N SQL запросов или 1 запрос?

что будет лучше, гадать что лучше или написать запрос и сделать explain?

что будет эффективнее, 3+N SQL запросов или 1 запрос?

На самом деле не получается сделать группировку внутри групп по количеству постов в нем

есть ситуации при которых "1 запрос" не очень эффективно, но это исключение из правила

На самом деле не получается сделать группировку внутри групп по количеству постов в нем

в смысле?

count + group by, ну и ты всегда можешь native sql замутить

замэпить результат count сразу в group твои всеравно не выйдет, можно было бы через "new" оператор в dql но доктрина пока не умеет так как тебе надо

замэпить результат count сразу в group твои всеравно не выйдет, можно было бы через "new" оператор в dql но доктрина пока не умеет так как тебе надо

Вот. На одном уровне вложенности то все нормально получается. У меня в голову идей не приходит как это сделать если агрегирование на втором и чтобы сразу все красиво было

делай селект групп и от них уже плеши

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

Кто нибудь в Workflow работал?

close: from: in_work to: closed cancel: from: [draft, new] to: cancelled cancel_admin: from: [draft, new, in_work, closed] to: cancelled

И когда я проверяю, $workflow->getEnabledTransitions((new Order())->setStatus('in_work'))

Он выдает мне только один транзишен :(

Вот результат.

Почему так?

Вот так выглядит workflow: https://pastebin.com/vr3gdpiq

Должно же 2 быть? close и cancel_admin, так?

Доброй ночи. Посоветуйте бандл для RSS. Сейчас юзаю Eko Feed но он не умеет в пагинацию.

@Enleur а можешь пример контроллера гистом кинуть?

https://gist.github.com/enleur/4d4a4ef3be7e36b693bfd4cdb58765d0 вот тут сделал пример с AbstractController и обычным сервисом с ограниченным контейнером

с таким подходом кстати сервисы можно держать приватными

https://gist.github.com/enleur/4d4a4ef3be7e36b693bfd4cdb58765d0 вот тут сделал пример с AbstractController и обычным сервисом с ограниченным контейнером

то есть у тебя по классу на экшен, так?

то есть у тебя по классу на экшен, так?

не, это для примера. а вообще можно через invoke да

что мне не нравится: - если у тебя больше чем один экшен на контроллер то не будет ли у тебя ситуации когда в класс инджектятся 10 зависимостей из которых на экшен используется только 3? - если у тебя только один экшен на контроллер, что там будет и чего там точно быть не может? Приведу пример - нам нужно получить репорт за последние 7 дней. Простая операция вычисления дэйт рэйнджа, она у тебя в контроллере будет или в сервисах? или быть может ты будешь юзать argument resolver?

я сейчас использую вариант следующий: - все операции вынесены в сервисы, по сервису на операцию (на юзкейс). - все что относится к циклу запрос/ответ - в контроллерах. - много экшенов в одном контроллере - сервисы инжжектятся как аргументы экшена, а не в конструктор. При этом работает и автовайринг и все сервисы можно делать приватными.

но мне этот вариант так же не нравится из-за абилия болейрплейта для простых операций

но ничего лучше придумать пока не смог (есть идие но они безумны пока)_

если сервисы не все используются в экшенах, то наверное этому экшену не место в контроллере

ну тогда мы приходитм со временем к ситуации где у тебя на один контроллер один экшен)

ну может 2

ну я не большой сторонник одного экшена в контроллере, особенно если нужен круд

давай круд возьмем

вот у тебя есть старый добрый crud для товаров. Есть update и есть delete

у тебя либо один сервис-менеджер либо у тебя разный набор зависимостей для этих действий

и следовательно ты delete например будешь выносить куда-то еще.

где я ошибся?

один сервис манагер да

ясно, не, мне такое не катит

ненавижу сервисы-менеджеры

их невозможно нормально тестами покрывать

окей, давай по другому

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

а что ты делаешь когда у тебя внутри менеджера происходит ситуация когда для двух операций нужны разные зависимости?

У меня в экшн идет параметром класс юзкейса.. ничего отдельно не настраиваю

ну вот у меня так же сейчас, и контроллер служит больше прослойкой для конвертации http в объекты приложения и обратно в респонс.

Меня вот подкупает в контроллерах через __invoke что не надо вручную парсить имена методов, если хочешь повесить общее поведение. Да и вообще попахивает процедурщиной. У меня был кейс, юзался жквери на фронте, а он слал запрос OPTIONS на некоторые роуты, я просто добавил интерфейс аля CanHandleOptions, проверял в event listener и в случае успеха отдавал специфичный респонс. Не знаю насколько это элегантно, но удалось убрать кучу копипасты)

хм.... OPTIONS запросы шлются с клиента для того что бы определить что можно делать с ресурсом (в твоем случае считай экшеном). Мол какие http verbs оно умеет и все такое. Ну и CORS.

немного непонятно зачем тебе этот инитерфейс и что в нем было

ибо по моему разумению все что касается options запросов можно захэндлить при помощи листенеров и на худой конец аннотаций

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

а так контроллеры через __invoke хороши когда у тебя юзкейсы в контроллере и реализованы, но тогда высока вероятность нарушить separation of concerns ибо если с реквестами все будет ок (ArgumentResolver-ы всякие и те же листенеры для того что бы скрыть http) то с респонсами уже не все так радужно и реализация будет напорядок сложнее....

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

ну короч много слишком НО и ЕСЛИ

Command/Query Separation короч позволяет красиво юзать __invoke контроллеры

Круто, столько нюансов, о которых раньше не задумывался, спасибо. По поводу options, нужно было возвращать пустой респонс с заголовками Access-Control-Allow-Origin, Access-Control-Allow-Headers и Access-Control-Allow-Methods, но при этом не выполнять логику контроллера. Я это и делал с помощью листенера, просто такой логику надо было сделать не в одном контроллерею. И получается, что в одном контроллере больше 1 экшена, надо парсить имена методов. А если через __invoke, то надо просто чекнуть instanceof и все.

» ArgumentResolver-ы всякие и те же листенеры для того что бы скрыть http Об этом задумываюсь. Мне в этом очень нравится идея request-objects

> И получается, что в одном контроллере больше 1 экшена, надо парсить имена методов. А если через __invoke, то надо просто чекнуть instanceof и все аннотации /** * @Route("/cool_stuff", methods={"POST"}) * @CORS() */ public function someCoolAction(SomeCoolService $service) { }

и проблема решена

> а так контроллеры через __invoke хороши когда у тебя юзкейсы в контроллере и реализованы, но тогда высока вероятность нарушить separation of concerns ибо если с реквестами все будет ок (ArgumentResolver-ы всякие и те же листенеры для того что бы скрыть http) то с респонсами уже не все так радужно и реализация будет напорядок сложнее.... это уже больше chain of interceptors, тогда отпадает смысл в привычных экшенах, можно рассматривать аргумент ресолверы, лисенеры, аппликейшен (домен) сервисы, трансформеры как равноправные элементы цепочки