Katulos
ну и тут https://www.doctrine-project.org/projects/doctrine-migrations/en/1.8/reference/generating_migrations.html чуть чуть
Katulos
там и alter всяко разный
Anonymous
@Basquash будет жить. Поприветствуем!
Dmitriy
Всем привет, начал изучать фрейм и встал такой вопрос, как пускать на страницу только не залогенных пользователей?
Dmitriy
access_control:
- { path: ^/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
попробовал вот так
Олексій
Всем привет, начал изучать фрейм и встал такой вопрос, как пускать на страницу только не залогенных пользователей?
А в чем смысл? Ведь можно вылогиниться и зайти туда
Dmitriy
А в чем смысл? Ведь можно вылогиниться и зайти туда
Не можно, я хочу чтобы нужно было так делать, страница сброса пароля та же самая, вошедшим пользователям там делать нечего...
Dmitriy
Всем привет, начал изучать фрейм и встал такой вопрос, как пускать на страницу только не залогенных пользователей?
Все, получилось вот так, но хз правильно ли это:
- { path: ^/login$, allow_if: "not is_granted('ROLE_USER')" }
Alexander
Все, получилось вот так, но хз правильно ли это:
- { path: ^/login$, allow_if: "not is_granted('ROLE_USER')" }
Лучше другую роль использовать. Точно не помню как звучит. REGISTERED_FULLY или типо того
Alexander
Т.к. потом у тебя другие роли появятся и не будет работать так как тебе нужно
Alexander
IS_AUTHENTICATED_FULLY
Alexander
Во
Dmitriy
Пытаюсь webpack контейнер для symphony настроить.
https://pastebin.com/XhqqbPWt
в docker-compose пытаюсь подмонтировать /var/www/src, но этой папки при сборки нет, как правильно контейнер собрать?
(только не кидайтесь какахами)
Dmitriy
Пытаюсь webpack контейнер для symphony настроить.
https://pastebin.com/XhqqbPWt
в docker-compose пытаюсь подмонтировать /var/www/src, но этой папки при сборки нет, как правильно контейнер собрать?
(только не кидайтесь какахами)
решил вопрос, полностью убил контейнер и заново собрал, не понял что это было такое
Katulos
Это был докер
Katulos
Не забывайте страдать 😊
Anonymous
@sliapcou будет жить. Поприветствуем!
Anonymous
@Narrator69 будет жить. Поприветствуем!
Anonymous
Ivan Levchuk будет жить. Поприветствуем!
Anonymous
@franzkafkiansky будет жить. Поприветствуем!
artem
Всем привет. Снова минутка глупых вопросов. Может быть кто-то видел паттерны кроме банды четырёх?
Maxim Kainov
https://designpatternsphp.readthedocs.io/ru/latest/README.html
artem
Суть вопроса в том что большинство было придумано больше 20 лет назад. Мб хоть что-то поновее есть
Евгений
Всем привет, у меня такой вопрос, есть fosuserbundle, и есть разные пользователи, типа администратора сервиса, пользователи моб. Приложения и партнёры со своим лк, это нормально что они все одной сущности в таблице fos_user? Понятно что у них разные роли
Евгений
Или лучше разносить этих пользователей?
Евгений
Кто как делает обычно?
Евгений
я обычно делаю разные сущности под пользователей со своим уникальном набором данных и потом линкую на fos_user (там общие данные), типа это одна точка входа, этого достаточно или вы вообще разносите по разным сущностям?
Вадим
Евгений
чтоб не дублировать данные для каждого типа пользоваителя
Евгений
у них все равно есть общие поля, типа имени, телефон, почта и прочее
Сергій 🍉
doctrine discriminator map, если есть разные поля, если нет, то и нет смысла разделять. имхо.
Вадим
doctrine discriminator map, если есть разные поля, если нет, то и нет смысла разделять. имхо.
Потом жить будет сложно
Вадим
у них все равно есть общие поля, типа имени, телефон, почта и прочее
Я считаю что такое обобщение зло. Таким образом появляется не нужное наследование, и не нужная зависимость
Вадим
И никакого профита
Сергій 🍉
а ты в сингл табле заверни
Сергій 🍉
потом жить будет не сложно
Maxim Kainov
И никакого профита
А если сделать one to many сущности типа AdminProperties, PartnerProperties и т.д.? Но лучше в одной таблице делать, если разных полей не слишком много
Вадим
потом жить будет не сложно
яблоки и помидоры бросать в один ящик, потому что они круглые. А когда придется сделать что-то яблочное или томатное, придется разгребать это все.
Maxim Kainov
Вадим
Админ это админ, пользователь это пользователь, у них разные функции и возможности. Потому я разделяю, т.к. нет смысла их держать вместе. Мало того, еще и креды отдельно, а сущность отдельно.
Вадим
А если сделать one to many сущности типа AdminProperties, PartnerProperties и т.д.? Но лучше в одной таблице делать, если разных полей не слишком много
Что значит разных полей. Имя собаки и имя человека, вроде одно и тоже "имя", но сущности то разные.
Maxim Kainov
Что значит разных полей. Имя собаки и имя человека, вроде одно и тоже "имя", но сущности то разные.
Создавай тогда таблицу на каждое животное )
Maxim Kainov
Ну так и делаю ;) админ, кастомер, менеджер и тд.
Можно еще разбить на бородатый админ и небородатый )
Вадим
Создавай тогда таблицу на каждое животное )
Все зависит от самой сущности, и ее методов, а не от того что у них одинаковые атрибуты.
Вадим
Можно еще разбить на бородатый админ и небородатый )
Нет, это уже больше похоже на свойство ;) Тоесть одна сущность ;)
Евгений
Все зависит от самой сущности, и ее методов, а не от того что у них одинаковые атрибуты.
в сущности минимум методлв, все выносится в сервисы
Maxim Kainov
Все зависит от самой сущности, и ее методов, а не от того что у них одинаковые атрибуты.
Если над сущностями нужно выполнять много одинаковых или похожих операций, имеет смысл обобщить эти сущности
Вадим
Вадим
Регистрация, авторизация
Регистрация недвижимости, и регистрация автомобиля, процесс тоже одинаково называется но он по факту разный
Maxim Kainov
Вадим
У них разная регистрация
Это сейчас ;) А когда ты разрабатываешь софт ты не знаешь как будет дальше ;)
Вадим
Почитай composition over inheritance
Вадим
https://en.wikipedia.org/wiki/Composition_over_inheritance
Maxim Kainov
Это сейчас ;) А когда ты разрабатываешь софт ты не знаешь как будет дальше ;)
Желательно знать. А если не знаешь, то конечно все сложнее становится )
Вадим
Желательно знать. А если не знаешь, то конечно все сложнее становится )
Приложение должно быть изменяемым
Вадим
Желательно знать. А если не знаешь, то конечно все сложнее становится )
В вики выше, посмотри пример, и поймешь в чем проблема
Сергій 🍉
яблоки и помидоры бросать в один ящик, потому что они круглые. А когда придется сделать что-то яблочное или томатное, придется разгребать это все.
плохая аналогия. есть же реальный кейс, зачем аналогии. админы и менеджеры - пользователи, у них больще похожих свойств, чем разных. дискриминация позволит не замарачиваться с логином, регистрацией, авторизацией и т.д. но в то же время вообще никак не мешает пользоваться ими как отдельными сущностями. кроме того сильно проще строить релейшены, например, потом надо тебе в пост добавить автора (юзера), а это может быть как админ, так и менеджер.
Сергій 🍉
но если сущности сильно отличаются по использованию в бизнесе, а общего почти ничего, то тогда да, лучше разделить. но в случае с юзерами обычно такого не происходит.
Вадим
плохая аналогия. есть же реальный кейс, зачем аналогии. админы и менеджеры - пользователи, у них больще похожих свойств, чем разных. дискриминация позволит не замарачиваться с логином, регистрацией, авторизацией и т.д. но в то же время вообще никак не мешает пользоваться ими как отдельными сущностями. кроме того сильно проще строить релейшены, например, потом надо тебе в пост добавить автора (юзера), а это может быть как админ, так и менеджер.
Что значит заморачиватся с логином и регистрацией? Регистрация у админа и пользователя разная. Нов твоем случае нужно иметь постоянный джоин + куча нулейбл полей, т.к. у пользователя в основном больше полей чем у админа. А все изза того, что тебе 2 свойства захотелось держать в одном классе ;)
Вадим
но если сущности сильно отличаются по использованию в бизнесе, а общего почти ничего, то тогда да, лучше разделить. но в случае с юзерами обычно такого не происходит.
Они всегда отличаются. Разве что ты клепаешь анемичные модели, то да пофиг ... И нет смысла заморачиватся ни с чем
Сергій 🍉
джоин не нужен при сингл тейбл, а нуллбл поля да, ну а как? где-то находишь где-то теряешь. а регистрация может и не отличаться. откуда тебе знать?
Вадим
джоин не нужен при сингл тейбл, а нуллбл поля да, ну а как? где-то находишь где-то теряешь. а регистрация может и не отличаться. откуда тебе знать?
Ну как минимум регистрация админа не общедоступная как у юзера, в основном у пользователя требуют подтверждение почты, итд.
Вадим
Ну в sti тебе where придется дописывать всегда, и помнить об этом
Сергій 🍉
Ну как минимум регистрация админа не общедоступная как у юзера, в основном у пользователя требуют подтверждение почты, итд.
в основном.. это как в среднем по больнице..
Сергій 🍉
кейс не я привел, и там вообще ни слова о том какая у кого должна быть регистрация.
Сергій 🍉
Сергій 🍉
а зачем where писать, доктрина все за тебя сделает
Anonymous
@Heman0 будет жить. Поприветствуем!
Maxim Kainov
Можно разделять и обобщать. Как лучше разделять и обобщать зависит от задачи