Ну так вот в примере показано — типа вставляйте в конструктор. Из этой строчки PHP$this->user = $user; видно что надо ещё и атрибуты обьявить
Laravel по-русски
Laravel по-русски
Ну так вот в примере показано — типа вставляйте в конструктор. Из этой строчки PHP$this->user = $user; видно что надо ещё и атрибуты обьявить
И какая там более сложная нечитаемая логика?
public function handle($request, Closure $next, $roles)
{
if (!is_array($roles)) {
$roles = explode(self::DELIMITER, $roles);
}
if ($this->auth->guest() || !$request->user()->hasRole(…Метод сохранения файла вернет имя файла, если он сохранился без проблем и его надо созранять в базу уже. Если модель не сохранилась в базу то файл желательно удалить что бы не засорять место на диске неиспользуемыми файлами. Да и путь незачем в базе хранить. Путь должен быть где то в конфиге, в базе только имя файла.
Данные — это данные, не обязательно база данных, хоть в текстовый файл можно писать, в том то и суть mvc что контроллеру все равно что там делает модель с данными, сохраняет их в MySQL, MongoDB, Redis, или в текстовый файл. Это уже в Ларавеле совместили модель с ORM и потому многие стали думать что модель и…
А вот ещё одна «хорошая» практика:
public function __construct(User $user)
{
$this->user = $user;
}
....
$this->user->create($request->all());
Что если понадобится два экземпляра User в каком то методе? Создавать две переменные? А если в…
Документация не описывает что это и как работает, она на уровне «зацените какая в ларавеле фича есть».
Стоимость разработки и поддержки ниже если надо пляски с бубнами?
Ну например нам не надо назначить ролям разрешения. Но все равно политики основываются на хардкоде. А если потом понадобится возможность редактировать роли то придется писать велосипед. Вы предлагаете велосипеды писать вместо того чтоб использовать готовое решение.
Вот эти политики на мой взгляд очень неудобные и громоздкие. В статье по ссылке рекомендуют использовать их а не, например, Entrust. Однако почему не обьясняется. В Entrust есть готовый middleware, который можно добавлять к роутам и группам роутов, и делается это намного проще, а тут так все запутанно. Писать кучу методов вручную, в разных файлов если можно взять готовую библиотеку. Более того, Entrust ещё содержит такую штуку как permissions, что позволяет пользователю самому определять что разрешено для конкретной роли. Это удобно для всяких CRM, где админ будет решать каким ролям пользователей что можно делать. Как сделать такую фичу…
Ты не совсем понимаешь что такое политики, поэтому рекомендую начать знакомство с ними с документации.
Почему следует использовать политики вместо сторонних решений? Потому что это стандартный инструмент фреймворка и стоимость разработки и поддержки при этом на порядок ниже.
Ну и один камень в огород overkill решений вроде Entrust - это проблемы с быстродействием (N+1, например), баги и более сложная (часто нечитаемая) итоговая логика. Эти проблемы возникают из-за неумения новичков обращаться с пакетами и из-за непонимания как именно они работают "под капотом". А именно новички, прочитав очередной туториал, начинают использовать этот пакет в каждом своем приложении, даже там, где есть всего две роли - пользователь и админ и нет необходимости динамически назначать разрешения.
← Назад | Дальше → Движется на Habravel
Я вот пока не понял для чего внедрять пустой экземпляр в класс контроллера.
Обычно внедряются прямо в метод
public function action(User $firstUser, User $secondUser){
...
}