idShura, ну не скриншотам же мне данные сюда кидать)) Вот из этих двух строк выводятся обе. А не одна Пробовал всяко. Не работает почему-то у меня(((((((
develop1, именно это я и хочу понять как лучше сделать. Я так пониманию, что нужно бакенду возвращать список разрешений: views-posts, manage-posts, manage-crm. Если такие разрешения есть, то показываем кнопку: CRM на боковом меню.
Правильно ли понял, что создаем свою базу. Парсим всю базу сразу к себе. и сохраняем рядом ID ФИАС. в проектах вставляем только ID города из своей базы. Нужно ли в таблице еще хранить id страны или получаем по городу?
Мне кажется такой себе подход))
Яндекс? Можно и яндекс. Просто видел, что в основном используют фиас.
Единственно не понимаю как лучше взаимодействовать и хранить. А может и вообще обойтись без ФИАС и просить пользователей просто добавлять города самим?)
Максим Федоров, в таком случае роль никак не попадает. Грубый пример на User. При создании User через конструктор мы добавляем и роль и статус. Поэтому в чистом виде ENUM использовать не хорошо, но если наследовать, то уже лучше. Однако я создам финальный класс Status наследованный от ENUM. Он будет общий. Но если я или кто-то захочет создать статус, в котором есть фабричные методы ::active() и ::publish(), то уже проблема. В таком случае мне надо создавать свой Status. Верно?) или я что-то не понимаю?
Спасибо за ответ) За библиотеку тоже спасибо. Есть несколько уточнений, которые так и не понял:
1. То есть все VO лучше делать финальными, верно?
2. Статус может быть VO, но если мы хотим иметь дополнительную функциональность - мы создаём другой VO Status, верно?
Конкретно ENUM использовать не хочу. Так как в одной сущности ENUM может быть два и более. Например, роль и статус. И уже есть вероятность поменять местами эти данные и в статус будет попадать роль. Поэтому, от этого хочу уйти своим типом, но с проверкой.
Иван Шумов, Например, есть такая доменная ошибка "Пользователь уже существует", "Токен просрочен", "Пользователь уже активирован" ... Их с каким кодом?
Егор Живагин, это понятно. Но всё равно есть какая-то хорошая практика? Просто сейчас с frontend dev обсуждаем. Он говорит что нужна ошибка 422 для валидации и 409 для domain. Я же сделал везде 400. Как быть?
А почему 422 для валидации не подходит? Мне кажется это, что нужно. 400 это неправильный запрос структуры. В нашем случае 422 это структура правильна, а данные не валидны
Administration это не просто какой-то uuid, но и ещё политики прав и группы доступа, которые должны авторизоваться и аутентифицироваться разными методами, плюс восстановление доступа, плюс обработка данных, + что угодно.
Вот у меня как раз тут совмещено все. Там и права доступа, и регитсрация и профиль... В целом это сложно объединить. Вот и гадаю сижу как это все назвать более правильно.
