Какую?

<argument type="service" id="logger" on-invalid="null"/>

https://symfony.com/doc/current/service_container/optional_dependencies.html#setting-missing-dependencies-to-null

Сейчас мозг сварится) кто-то делал авторизацию через разные сущности с lexik jwt? Например один вход для юзверя, другой для админа

Сейчас мозг сварится) кто-то делал авторизацию через разные сущности с lexik jwt? Например один вход для юзверя, другой для админа

Юзер и админ это пользователи. Одна сущность должна быть

Юзер и админ это пользователи. Одна сущность должна быть

С чего это одна сущность?

Юзер и админ это пользователи. Одна сущность должна быть

А если по бизнесу админ может с теми же данными быть юзером?

С чего это одна сущность?

А с чего разные?

А с чего разные?

Ответь сначала почему одна

Ответь сначала почему одна

Потому что для тех и других нужно выполнять одинаковые операции

Упрощение

Айдишник уникальный должен быть

Потому что для тех и других нужно выполнять одинаковые операции

Но возможности у них разные. Если сантехник и повар выполняет одинаковые операции, ест, пьет и ходит в туалет, это не означает что это один и тот же человек

Говно, классы можно наследовать от одного абстрактного "пользователь", но администратор и клиент (юзер) должны быть отдельными сущностями

Говно, классы можно наследовать от одного абстрактного "пользователь", но администратор и клиент (юзер) должны быть отдельными сущностями

Смысл их наследовать?

Ну, общие какие-то переменные могут быть

Можно и не наследовать, бога ради

Ну, общие какие-то переменные могут быть

У сущностей не должно быть переменных

Но возможности у них разные. Если сантехник и повар выполняет одинаковые операции, ест, пьет и ходит в туалет, это не означает что это один и тот же человек

А если у тебя повар будет еще выполнять обязанности сантехника?

У сущностей не должно быть переменных

Хорошо, проперти

Как ты это реализуешь

Как ты это реализуешь

Трейтами конечно

Но это другой вопрос

А если у тебя повар будет еще выполнять обязанности сантехника?

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

Хорошо, проперти

И пропертей видно быть не должно. Только методы, а как там внутри все устроено, вот вообще не должно волновать клиентский код.

Трейтами конечно

Зачем трейты?

И пропертей видно быть не должно. Только методы, а как там внутри все устроено, вот вообще не должно волновать клиентский код.

Да ну? В энтити не должно быть например private $id?

Или ты про видимость уже перескочить успел

Да ну? В энтити не должно быть например private $id?

Ключевое слово private ;) Оно не видно наружу. Внутри хоть private $fields=[]

Ну тогда да, ты прав, видны только методы

И пропертей видно быть не должно. Только методы, а как там внутри все устроено, вот вообще не должно волновать клиентский код.

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

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

Зачем тогда тебе сущность и orm?

Вообще не в ту степь ушли) сейчас бы реализацию по jwt найти, или хотя бы схему понять. Я все ещё думаю что можно разрулить на ролях

Вообще не в ту степь ушли) сейчас бы реализацию по jwt найти, или хотя бы схему понять. Я все ещё думаю что можно разрулить на ролях

На хабре недавно статья про две точки входа была

Вообще не в ту степь ушли) сейчас бы реализацию по jwt найти, или хотя бы схему понять. Я все ещё думаю что можно разрулить на ролях

https://habr.com/ru/post/508936/

Зачем тогда тебе сущность и orm?

Сущность у тебя может быть структурой, с которой работают другие объекты. Но геттеры сеттеры лучше наверное все таки сделать на всякий случай )

https://habr.com/ru/post/508936/

Просто красавчик! Думал сутки хоть что-то похожее буду искать

Сущность у тебя может быть структурой, с которой работают другие объекты. Но геттеры сеттеры лучше наверное все таки сделать на всякий случай )

Работай с массивом, в чем проблема. А гетеры сетеры не особо нужны, если обьект. Tell don't ask

Работай с массивом, в чем проблема. А гетеры сетеры не особо нужны, если обьект. Tell don't ask

Через орм лучше работается

Просто красавчик! Думал сутки хоть что-то похожее буду искать

только в статье для обычных форм авторизации с jwt тебе это в принципе нафиг не нужно создай свой Authenticator в getUser $data = $this->jwtEncoder->decode($credentials); if($data['role'] === 'admin') { $user = $this->em->getRepository(Admin::class) ->find($id); } else { $user = $this->em->getRepository(User::class) ->find($id); } return $user; соответственно при логине в токен надо добавить соответствующий role

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

Один к примеру memory другой entity

Через chain provider

Или вопрос не о том?

Или вопрос не о том?

С чейном. Логика как и думал. Распилю энтри и отпишу как мб

вопрос не ясен)

можно добавить геттеры и обозначить их аннотацией internal (https://docs.phpdoc.org/latest/references/phpdoc/tags/internal.html), если найду первоисточник то скину

а на итоговую коллекцию тоже нет геттера?

(в качестве мозгового штурма) а если через рефлексию сделать проперти пабликами?

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

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

Тоесть на эти диапазоны никакой логики нет?

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

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

я так понял, что пишутся в приватное свойство persist flush читается через дбал "где-то там в другом месте"

я так понял, что пишутся в приватное свойство persist flush читается через дбал "где-то там в другом месте"

Получается, что от этих данных ничего не зависит, тогда зачем их тестировать? ;)

я так понял, что пишутся в приватное свойство persist flush читается через дбал "где-то там в другом месте"

Нет смысла тестировать персистенс слой

Нет смысла тестировать персистенс слой

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

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

Запрос в базу тогда ;)

Но кмк это фигня

Запрос в базу тогда ;)

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

но вместо бубнов проще сделать геттер)))

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

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

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

Привет. А кто-то работал с knp translation behavior? Вроде бандл настроил, все работает. Вот пока хз как отдавать сущности с текущей локалью. Мб не нашёл ещё доки

Привет. А кто-то работал с knp translation behavior? Вроде бандл настроил, все работает. Вот пока хз как отдавать сущности с текущей локалью. Мб не нашёл ещё доки

Разобрался?

Разобрался?

Нет. Спал)

Ну я так понял оно по дефолту и так отдает в текущей локали

https://github.com/KnpLabs/DoctrineBehaviors/blob/master/src/Provider/LocaleProvider.php

Как установить текущую локаль в симфе читай доку симфы

"id": 53, "title": "Miss", "translations": [ { "id": 56, "title": "ru тайтл", "locale": "ru" }, { "id": 55, "title": "укр тайтл", "locale": "ua" } ], "new_translations": null, "current_locale": "ua", "default_locale": "ua" что то не верится

Добрый день. Установил Sf4.4+sonata_admin3.65 locale 'ru'. В Admin классе в методе configureListFields настроил поле даты как editable. Окно календаря работает, но отображается на англ.яз. Как установить для окна календаря: 1) отображение надписей на русском языке; 2) заданную (не текущую) дату. Подробности: https://groups.google.com/d/msg/sonata-users/lqaNcqXjPA8/YuAo0FrRAgAJ Спасибо

Добрый день. Установил Sf4.4+sonata_admin3.65 locale 'ru'. В Admin классе в методе configureListFields настроил поле даты как editable. Окно календаря работает, но отображается на англ.яз. Как установить для окна календаря: 1) отображение надписей на русском языке; 2) заданную (не текущую) дату. Подробности: https://groups.google.com/d/msg/sonata-users/lqaNcqXjPA8/YuAo0FrRAgAJ Спасибо

Состав пакета sonata core-bundle

Состав пакета sonata admin-bundle

Из примеров editable поля в List View в инете нашел очень далекое https://gitmemory.com/issue/sonata-project/SonataAdminBundle/5767/559738217 по образу которого с помощью {% extends '@SonataAdmin/CRUD/base_list_field.html.twig' %} {% block field_span_attributes %} {{ parent() }} data-clear="Х очистить" {% endblock %} в окне календаря изменил надпись с "X clear" на "Х очистить"

сегодня день локализации)) добрался до переводов ассертов и тоже трабла. когда в translation.default_locale меняю языки то ошибки переводятся, добавил листенер чтобы задавать локацию $event->getRequest()->setLocale($locale); с доков все равно отдает с default_language. мб ктосталкивался?

у меня такой код в сабскрайбере public function setLocale(RequestEvent $event): void { $request = $event->getRequest(); $locale = $request->getPreferredLanguage(); if ($locale !== null) { $request->setLocale($locale); } } работает нормально

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

спс, попробую

https://symfony.com/doc/current/session/locale_sticky_session.html для 5.1 точно работает

Добрый день. Установил Sf4.4+sonata_admin3.65 locale 'ru'. В Admin классе в методе configureListFields настроил поле даты как editable. Окно календаря работает, но отображается на англ.яз. Как установить для окна календаря: 1) отображение надписей на русском языке; 2) заданную (не текущую) дату. Подробности: https://groups.google.com/d/msg/sonata-users/lqaNcqXjPA8/YuAo0FrRAgAJ Спасибо

Зачем соната? Изиадмин же есть

Зачем соната? Изиадмин же есть

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