Похоже, да

причем, включить через kernel events

ну либо пойду гуглить, как он на entity включается

ну либо пойду гуглить, как он на entity включается

is_enabled ?

is_enabled ?

Да

фильтр

задача - на публичной части фильтр включить, в админке выключить на списке entity

is_enabled: type: boolean

да, так

И ?

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

сделал по аналогии со статьей, выше приводил - работает

Так в чем тогда проблема ?

Если работает

Возможно есть способы проще

Способ проще от тебя зависит, если ты понял смысл как это работает

) возможно. Ну в любом случае, задача пока решена, потом можно подумать о том, как улучшить решение.

Привет, подскажите bestpracticies, стоить ли каждому методу в сервисе отвечающему за изменение сущности и её зависимостей добавлять что-то вроде $flush = true аргумента? Например, когда вызывается метод извне сервиса и изменяется только один объект, то ждать других изменений нет смысла и можно сразу зафлушить изменения. Но есть методы, которые сначала изменяют сущность, потом обращаются к другим методам, изменяющим их отношения и т.д. Получается цепочка из методов, в каждом из которых есть $em->flush(). И чтобы лишний раз не обращаться к бд, думаю везде предусмотреть последним аргументом данное решение. Насколько это правильно и кто-то делает также\похоже?

Привет, подскажите bestpracticies, стоить ли каждому методу в сервисе отвечающему за изменение сущности и её зависимостей добавлять что-то вроде $flush = true аргумента? Например, когда вызывается метод извне сервиса и изменяется только один объект, то ждать других изменений нет смысла и можно сразу зафлушить изменения. Но есть методы, которые сначала изменяют сущность, потом обращаются к другим методам, изменяющим их отношения и т.д. Получается цепочка из методов, в каждом из которых есть $em->flush(). И чтобы лишний раз не обращаться к бд, думаю везде предусмотреть последним аргументом данное решение. Насколько это правильно и кто-то делает также\похоже?

По ситуации. Лучше стараться поближе к контроллеру делать флаш, мне кажется.

По возможности лучше не делать такой параметр

Привет, подскажите bestpracticies, стоить ли каждому методу в сервисе отвечающему за изменение сущности и её зависимостей добавлять что-то вроде $flush = true аргумента? Например, когда вызывается метод извне сервиса и изменяется только один объект, то ждать других изменений нет смысла и можно сразу зафлушить изменения. Но есть методы, которые сначала изменяют сущность, потом обращаются к другим методам, изменяющим их отношения и т.д. Получается цепочка из методов, в каждом из которых есть $em->flush(). И чтобы лишний раз не обращаться к бд, думаю везде предусмотреть последним аргументом данное решение. Насколько это правильно и кто-то делает также\похоже?

Не стоит, т.к. цепочки вызовов невозможно проследить.

Не стоит, т.к. цепочки вызовов невозможно проследить.

Что значит невозможно проследить?

Что значит невозможно проследить?

Поменялся порядок вызова методов сервиса, например. Правильно выше сказали - флаш лучше в контроллере вызывать

Когда уже очевидно, что вся внутрення логика отработала

Понял, спасибо

Добрый вечер. Подскажите, кто работает плотно с fosrest: Как в post - методах, принимать массив id подсущностей так, чтобы они сразу конвертились в сущности и ставились сущности, которой приходит в контроллер сразу чайлдами. Ну, например: Есть класс учитель, у учителя есть уроки. Сейчас мне в контроллер приходит учитель (Request Body Converter Listener), я хочу, чтобы с фронта мне также слали массивчик: "уроки": [ 1, 5 ,7 ] и этот массивчик сразу конвертился в сущности, и цеплялся к учителю

Кто как хранит вспомогательные функции, которые могут быть востребованы в любом месте проекта? Создаёте класс отдельный и static методы определяете или как?

Что-то типа Utilities/Helper

Кто как хранит вспомогательные функции, которые могут быть востребованы в любом месте проекта? Создаёте класс отдельный и static методы определяете или как?

Да так

А если в отдельный бандл их запаковать, чтобы без статики инжектить?

🤯

Не надо паковать ничего в бандл

инжектить без статики можно и без бандла)

Кто как хранит вспомогательные функции, которые могут быть востребованы в любом месте проекта? Создаёте класс отдельный и static методы определяете или как?

Да, но в идеале, конечно, такого быть не должно.

Т.е. лучше в сервисе трижды написать один и тот же кусок форматирования?

$date = new \DateTime(); $date->setTimezone(new \DateTimeZone($name)); return $date->format('T'); $date = new \DateTime(); $date->setTimezone(new \DateTimeZone($name)); return $date->format('T'); $date = new \DateTime(); $date->setTimezone(new \DateTimeZone($name)); return $date->format('T');

Т.е. лучше в сервисе трижды написать один и тот же кусок форматирования?

Нет, лучше это вынести в отдельный сервис

В чем проблема? В ентити надо вызывать?

Сервисы вроде как должны делать больше бизнес-логику, чем обработку универсальных данных

Я не эксперт, просто интересно

Чем лучше хранить в сервисе, нежели в обычном классе

Сервисы вроде как должны делать больше бизнес-логику, чем обработку универсальных данных

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

В одних бизнес логика, в других еще что то

Да, но в идеале, конечно, такого быть не должно.

Почему?

Почему?

Ну погугли, чем плохи статические методы

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

Зачем вообще di контейнер придумали, делали бы статику везде, да и все )

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

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

Ты же не знаешь, что дальше будет. Со временем контейнер может понадобиться, и тебе придется все переделывать. Лучше уж сразу в виде сервиса сделать, тем более это несложно.

Ты же не знаешь, что дальше будет. Со временем контейнер может понадобиться, и тебе придется все переделывать. Лучше уж сразу в виде сервиса сделать, тем более это несложно.

Ну ну, какой-нибудь DateHelper с форматированием дат у него превратится в сервис

ну вот конкрентно в этом примере - думаю врядли

в фабрику фабрик, выпускающую фабрики

а если и так, сделать его сервисом - тоже дело оч простое

Ну и лучше не просто Helper, а какой-нибудь DateHelper

Ну и лучше не просто Helper, а какой-нибудь DateHelper

Ну это уже запилил)

Это че за хренотень то

как будто вендоры частино обновились) ничего не обновляли?

пиндец

Поставил 5.1.3 сф

Доктрину обновили

Походу deprecated убрали

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

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

версии: "doctrine/doctrine-bundle": "^2.0", "sensio/framework-extra-bundle": "^5.6", должны быть

Пока только это решение проблемы

Да на даче стоит

Дизельный

Что именно тебе не понятно в генераторах

С помощью генератора ты можешь генерировать один элемент за вызов

Тоже не понимаю зачем генератор ентити, если проще скопипастить

В добавок мейкер все делает в захардкоженных дефолтных каталогах

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

В добавок мейкер все делает в захардкоженных дефолтных каталогах

В основном у всех дефолтные каталоги

Товарищи, а можно ли отключить фильтр доктриновский на уровне ParamConverter? а то невозможно entity подгрузить для редактирования в админке - вешается isEnabledFilter на запрос.

Товарищи, а можно ли отключить фильтр доктриновский на уровне ParamConverter? а то невозможно entity подгрузить для редактирования в админке - вешается isEnabledFilter на запрос.

Решил через переопределение метода в @Entity (expr=«repository.method(id)»)

Ребят, скажите пожалуйста, anonymous: false в security.yaml - производит редирект, но симфони как api.. нужно просто возвращать 401 для неавторизованных.. Как это реализовать? Просто щас делает мой коллега так, в каждой аннотации указывает проверку, is_granted, что авторизован.. и после этого возвращает ошибку автоматом.. но в каждом контроллере писать в анотации - как мне кажется немного напряжно.. лучше в 1 файле описать .. Есть такоя опция?

а какой у вас аутентификатор используется? или свой guard?

покажи настройку firewall для /api

если guard - в функции start 401 верни и все.

security: # https://symfony.com/doc/current/security.html#where-do-users-come-from-user-providers providers: # used to reload user from session & other features (e.g. switch_user) app_user_provider: entity: class: App\Entity\User property: email firewalls: dev: pattern: ^/(_(profiler|wdt)|css|images|js)/ security: false main: # pattern: ^/ anonymous: true security: true remember_me: false guard: authenticators: - App\Security\LoginFormAuthenticator # https://symfony.com/doc/current/security/impersonating_user.html # switch_user: true encoders: App\Entity\User: algorithm: bcrypt cost: 12