N
Nikolay Cherniy
ну если ты пытаешься изолировать корзину от юзера это и так можно сделать без сигналов
Можно, но тут вопрос, в каком приложении создавать функцию, которая создаёт корзину при создании пользователя
Size: a a a
2020 October 08
N
В сейв пользователя я пихать не хочу, так как выше расписал почему. А сигнал хорошее решение "на время", которое затем просто переписать, когда уже подумаешь как должно быть
NC
Можно, но тут вопрос, в каком приложении создавать функцию, которая создаёт корзину при создании пользователя
а зачем корзину создавать при создании пользователя? она же просто ссылается на пользователя, а создается когда он чего-то заказывает
N
Nikolay Cherniy
а зачем корзину создавать при создании пользователя? она же просто ссылается на пользователя, а создается когда он чего-то заказывает
Ну это абстрактный пример. Во многих проектах она сразу же создаётся или схожие модели. Например профили юзера
VD
Nikolay Cherniy
а зачем корзину создавать при создании пользователя? она же просто ссылается на пользователя, а создается когда он чего-то заказывает
+
N
У меня есть 5 различных профилей у пользователя, которые он должен заполнять, и чтобы знать, которые нужно ему заполнить, я создаю емпти профили со статусом заполнения - Фальш
Это пример из моего проекта
Это пример из моего проекта
NC
В принципе идея ясна, может быть когда буду делать 10 однотипных приложений за неделю осознаю что такой подход хорош, но пока останусь при своем)
VD
Ну это абстрактный пример. Во многих проектах она сразу же создаётся или схожие модели. Например профили юзера
И профиль не должен создаваться при создании пользователя. Создаваться он должен, когда будет необходимая для создания информация, т.е. после заполнения всех полей формы.
N
И профиль не должен создаваться при создании пользователя. Создаваться он должен, когда будет необходимая для создания информация, т.е. после заполнения всех полей формы.
Ну это ты так считаешь, а мой менеджер нет
N
Например мы можем сразу пустые профили смотреть и руками их апдейтить людям, которые сами не могут
(Проект для дистанционного мониторинга онкобольных)
Т.е. у людей в админке, которые имеют роль оператора, есть только пермишен на апдейт
Из-за недоступности create нужно создавать профили сразу. Защита от дурака такая
(Проект для дистанционного мониторинга онкобольных)
Т.е. у людей в админке, которые имеют роль оператора, есть только пермишен на апдейт
Из-за недоступности create нужно создавать профили сразу. Защита от дурака такая
А
И профиль не должен создаваться при создании пользователя. Создаваться он должен, когда будет необходимая для создания информация, т.е. после заполнения всех полей формы.
да, на каждую роль по модели с данными, юзер как покупатель - отдельно у него есть Кастомер, юзер как Продавец, например, у него есть модель Вендор и т.д., нафига эти заглушки создавать пустые?
А
заодно и с правами просто, смотришь, есть такая связь у юзера или нет
N
И профиль не должен создаваться при создании пользователя. Создаваться он должен, когда будет необходимая для создания информация, т.е. после заполнения всех полей формы.
Создание профиля, нужно или нет зависит от задач проекта. Нельзя просто так утверждать "не должен", не зная контекста. Как и пример с корзиной. Иногда это нужно делать в связи со спецификой проектов
N
Например при реге чтобы в корзине в первый раз были бонусы с промокода
DT
Вообще, на самом деле, что касается промо, я сейчас пришел к тому, что модуль для выссчитывания промо акций - это всегда отдельная такая прибамбасина, она может даже находиться не внутри приложения.
DT
И при проектировании архитектуры - это очень абстрактная вещь, где правила промо-акций задаются практически псевдокодом
NC
Создание профиля, нужно или нет зависит от задач проекта. Нельзя просто так утверждать "не должен", не зная контекста. Как и пример с корзиной. Иногда это нужно делать в связи со спецификой проектов
если у юзера один привязанный профиль который должен быть всегда, то вопрос почему не кастомный юзер. Если несколько профилей - то они не привязываются и не создаются все, а если все же создаются, то выглядит это как не очень удачно архитектурное решение. Но это имхо
DT
Иначе, взбредет в голову бизнесу сделать промо акцию каждый пятый рожденный по лунному календарю мужчина-трансвестит, у которого левое яичко весит больше чем масса всех его ногтей, получает скидку в размере длины самого длинного волоса
DT
И приходится костылять это внутри бизнес логики приложения.
AG
Nikolay Cherniy
если у юзера один привязанный профиль который должен быть всегда, то вопрос почему не кастомный юзер. Если несколько профилей - то они не привязываются и не создаются все, а если все же создаются, то выглядит это как не очень удачно архитектурное решение. Но это имхо
я вот согласен с @Nire1, если учитывать специфику которую он описал, то создавать за юзеров профили - это норм. Автоматизация и исключение пользовательских ошибок)