Ш
Size: a a a
2020 July 29
IL
IL
давайте продвигать руби)
CR
да я со стрима
IL
да он не будет
v.
Подскажите, как грамотно разделить 'полномочия' пользователей
Имеется:
Модель
Модель
1. один
Pros:
простая организация
Cons:
большая запутанная вьюха,
большие экшны в контроллере
проверки ролей не только во вьюхе, но и в контроллере
небезопасно, т.к можно не заметить и предоставить не те полномочия
2. создать namespaces
через CanCanCan разграничить доступ к неймспейсам для ролей
Pros:
четкое разделение логики для ролей
легко контролировать полномочия
Cons:
много дублирования, не DRY
тяжело в реализации и поддержке
3. как 1й вариант, только все полномочия прописать в CanCanCan-вском ability.rb
Pros:
более наглядное представление полномочий
Cons:
вместо условий
Имеется:
Модель
Users, роли: 'Client', 'Creator'Модель
Project
вьюха на Projects#show
достаточно большие различия в отображении и функционале для client и creator
также некоторые экшны нужны только для одной роли1. один
ProjectsController, одна вьюха, show в ней постоянные проверки is_client?, is_creator?
в зависимости от этого рендерить нужные partials из этой вьюхиPros:
простая организация
Cons:
большая запутанная вьюха,
большие экшны в контроллере
проверки ролей не только во вьюхе, но и в контроллере
небезопасно, т.к можно не заметить и предоставить не те полномочия
2. создать namespaces
client, creator
КонтроллерыClientControllerв них нужные экшны
CreatorController
ProjectController
Client::ProjectsController < ClientController
Creator::ProjectsController < CreatorController
через CanCanCan разграничить доступ к неймспейсам для ролей
Pros:
четкое разделение логики для ролей
легко контролировать полномочия
Cons:
много дублирования, не DRY
тяжело в реализации и поддержке
3. как 1й вариант, только все полномочия прописать в CanCanCan-вском ability.rb
Pros:
более наглядное представление полномочий
Cons:
вместо условий
is_client?, is_creator? придется писать столько же проверок, только в виде can?AN
Вадим, может разделить на два стрима?
CR
два разных пользователя с разными инструментами, по моему логично, что разные контроллеры могут быть для них.
и с DRY тоже не нужно перебарщивать
и с DRY тоже не нужно перебарщивать
RM
Подскажите, как грамотно разделить 'полномочия' пользователей
Имеется:
Модель
Модель
1. один
Pros:
простая организация
Cons:
большая запутанная вьюха,
большие экшны в контроллере
проверки ролей не только во вьюхе, но и в контроллере
небезопасно, т.к можно не заметить и предоставить не те полномочия
2. создать namespaces
через CanCanCan разграничить доступ к неймспейсам для ролей
Pros:
четкое разделение логики для ролей
легко контролировать полномочия
Cons:
много дублирования, не DRY
тяжело в реализации и поддержке
3. как 1й вариант, только все полномочия прописать в CanCanCan-вском ability.rb
Pros:
более наглядное представление полномочий
Cons:
вместо условий
Имеется:
Модель
Users, роли: 'Client', 'Creator'Модель
Project
вьюха на Projects#show
достаточно большие различия в отображении и функционале для client и creator
также некоторые экшны нужны только для одной роли1. один
ProjectsController, одна вьюха, show в ней постоянные проверки is_client?, is_creator?
в зависимости от этого рендерить нужные partials из этой вьюхиPros:
простая организация
Cons:
большая запутанная вьюха,
большие экшны в контроллере
проверки ролей не только во вьюхе, но и в контроллере
небезопасно, т.к можно не заметить и предоставить не те полномочия
2. создать namespaces
client, creator
КонтроллерыClientControllerв них нужные экшны
CreatorController
ProjectController
Client::ProjectsController < ClientController
Creator::ProjectsController < CreatorController
через CanCanCan разграничить доступ к неймспейсам для ролей
Pros:
четкое разделение логики для ролей
легко контролировать полномочия
Cons:
много дублирования, не DRY
тяжело в реализации и поддержке
3. как 1й вариант, только все полномочия прописать в CanCanCan-вском ability.rb
Pros:
более наглядное представление полномочий
Cons:
вместо условий
is_client?, is_creator? придется писать столько же проверок, только в виде can?Вообще можно сделать три модели еще. Такое видел.
2020 July 30
AN
Вадим ты не против?
AN
У многих при начале работы с рельсами возникает куча вопросов:
— Можно ли установить рельсы на винде?
— Почему для установки руби нужен rvm?
— У меня ничего не работает, помогити!
Я решил сделать стрим про установку 6-х рельс (ставить будут на Windows с помощью WSL, но расскажу про все ОС).
Поговорим про окружение и инструменты: apt-get, rvm, bundler, yarn, nodejs.
Вкратце расскажу, как работают рельсы и разберем какая папка в рельсах для чего нужна.
В процессе поучимся не ныть, если что-то не сработало, включать башню, анализировать ситуацию и искать решения в интернете. Без этого никуда.
📅 Стрим будет завтра, 29 июля в 19:00
🚊 Ссылка на трансляцию: https://youtu.be/yVqgWzukCRE
https://youtu.be/yVqgWzukCRE
Если хотите напоминалку на email утром и за полчаса до стрима, оставьте почту здесь: gprg.dev/r/6433gprg.dev/r/6433.
— Можно ли установить рельсы на винде?
— Почему для установки руби нужен rvm?
— У меня ничего не работает, помогити!
Я решил сделать стрим про установку 6-х рельс (ставить будут на Windows с помощью WSL, но расскажу про все ОС).
Поговорим про окружение и инструменты: apt-get, rvm, bundler, yarn, nodejs.
Вкратце расскажу, как работают рельсы и разберем какая папка в рельсах для чего нужна.
В процессе поучимся не ныть, если что-то не сработало, включать башню, анализировать ситуацию и искать решения в интернете. Без этого никуда.
📅 Стрим будет завтра, 29 июля в 19:00
🚊 Ссылка на трансляцию: https://youtu.be/yVqgWzukCRE
https://youtu.be/yVqgWzukCRE
Если хотите напоминалку на email утром и за полчаса до стрима, оставьте почту здесь: gprg.dev/r/6433gprg.dev/r/6433.
Кто не смотрел стрим ВСЕМ советую посмотреть. Вадим красавчик, все разложил по полочкам👍
В
Там опечатка - rubirush
В
Владислав
Там опечатка - rubirush
И два раза Второй