jazzus

LAravel Resource
Нужно сделать
php artisan make:resource PostResource
В этом файле прописать

public function toArray($request)
    {
        return [
            'id' => $this->id,
            'name' => $this->name,
           // Метод из модели
            'thumb' => $this->thumb(),
        ];
    }

И в контроллере в шапке подключаем use App\Http\Resources\PostResource as PostResource;
и передаем json в методе

public function getPosts()
  {
     $posts = Post::all();
     return PostResource::collection($posts); 
  }

Можно попробовать со скопом в модели User

public function scopeOfLogins($query, $logins)
{
         $builder = $query->whereIn('login', $logins)
                         ->with(['posts' => function($q){
                                      $q->take(5);
                                     }]);
    return $builder;
}

в контроллере

$logins = ['ivanov', 'petrov'];
$users = User::ofLogins($login)->get();

или с форычем в юзере

public function scopeOfLogins($query, $logins)
{
    foreach ($logins as $login) {
         $builder = $query->where('login', $login)
                           ->with(['posts' => function($q){
                           $q->take(5);
                           }]);
    }
    return $builder;
}

По-моему так выводят html в формате html. Чтобы не<b>велосипед</b> отображалось, а велосипед

Можно пройтись форычем по реквест ол и собрать в билдер нужный запрос. Типа

foreach ($request->all() as $name => $value)
        {
          // Если название метода совпадает с названием параметра из реквеста
          if (method_exists($this, $name))
          {
            //Запускаем методы
            $this->$name($value);
          }
        }
        //В конце возвращаем собранный билдер для дальнейшего использования
        return $this->builder;

ну и методы фильтров сделать типа

public function name($value)
  {
     $this->builder->where('name', 'like', "%$value%");
  }

это, конечно если я правильно понял что нужно. В общем в качестве идеи) Но перечислять весь реквест, конечно не нужно, замучаешься рефакторить. Плюс нельзя к реквесту обращаться вот так $request->tehnical Только через инпут или гет Эх новички новички..))

Если только с моделью, контроллером без отдельного класса - то еще вариант :
Делаете в модели Specialnosti скопы (названия должны начинаться со scope)

public function scopeOfUniverById($query, $request)
    {
      foreach ($request->all() as $id)
          {
              $builder = $query->where('univer_id', $id);
          }
        return $builder;
    }

и в контроллере

$spec = Specialnosti::ofUniverById($request)->get();

я не тестировал, но по идее должно работать)

В модели property к отношению items()

public function filterItems($value)
  {
    return $this->items()->wherePivot('value', $value);
  }

и затем в контроллере

$value = 1;
$items = Property::find(5)->filterItems($value)->get();

Как бы не хотелось сейчас создать 3 таблицы для одинаковых сущностей – не делайте этого. Совет от новичка) Потом замучаетесь рефакторить, а рефакторить структуру бд – это все сносить и делать заново. И вы будете это делать. Потому что юзеры в разных таблицах принесут вам проблемы.

Нужно сделать модели (таблицы)
User (все пользователи)
Role (именование ролей – учителя, ученики и т.д.)
UserRole (с полями user_id и role_id)

User связывается с Role через ManyToMany
В модели user

public function roles()
    {
      return $this->belongsToMany('App\Role', 'user_roles', 'user_id', 'role_id');
    }

В модели Role

public function users() {
        return $this->belongsToMany('App\User', 'user_roles', 'role_id', 'user_id');
      }

Можно проще записать но лучше так. Теперь у вас есть связь между ролями и юзерами через промежуточную таблицу 'user_roles'. Почему именно так:
1) У вас будет одна таблица вместо 10 для любых изменений, связанных с пользователями. Например, добавить новое поле, изменить поле ит.д. Вы это будете делать 1 раз, а не 10, исключая ошибки человеческого фактора
2) Вы захотите добавить правила доступа. А для этого нужна будет еще одна таблица Perm. Которая будет привязана к ролям. И сделать это будет легко и просто в данной структуре и права доступа вы потом будете менять в несколько кликов.
3) С несколькими таблицами юзеров у вас будет запутанная раздутая логика со множеством моделей, переменными , вы замучаете ларавелю, запутаетесь сами и снесете все нафиг.

Ладно, модели создали)) Теперь при регистрации добавим роль пользователю. Допустим учитель регистрируется и выбрает себе роль учитель (пускай будет чекбокс с полем role где value это ид роли).

В контроллере регистрации (если стандартном ларавелевском) идете в метод
protected function create(array $data)

и пишете после создания юзера

$user->roles()->attach($data['role']);
После чего у вас автоматом создастся запись в промежуточной таблице и юзеру будет присвоена роль учителя. Готово. Теперь вы можете делать все что угодно.

Например
получить пользователей указанной роли в контроллере

$teachers = Role::find(3)->users()->get();
Правильно написал? только цифры нужно поменять на константы и вообще лушче сразу в модели написать один метод для получения юзеров любых ролей (подставлять название константы роли через переменную) – но это ладно, потом просто передалть. На этом все) Только после создания ролей можно приступать к группам и это уже нужно выносить в отдельный вопрос.

Создать связующие таблицы между всеми сущностями в отношениях, сделать связь в моделях многие ко многим и делать потом записи в связующих таблицах через метод ->attach()

Попробуйте прописать дополнительно use App\Http\Requests;
И лучше валидировать отдельным реквест файлом чтобы код потом не дублировать

@if ($title)
     {{ $title }}
@else
'Default'
@endif

Как сделать универсальный вид? В одной таблице. На каждую сущность - своя таблица (так говорят).
admins лучше не создавать. Т.к. это пользователь, а у вас уже есть users. Лучше сделать таблицу roles и туда поместить роль admin и уже присвоить роль конкретному юзеру в промежуточной таблице user_roles с полями user_id и role_id
Создаем модель c миграцией:
php artisan make:model Models/Название модели -m
И там прописать поля таблицы (примеры в доках).
Выгрузить миграцию в базу командой php artisan migrate

Не знаю насколько поможет мой опыт т.к. я сам только учусь) но я сделал так:

3 таблицы

Roles
role_perms
perms

Связываем роли и пермы через manytomany.

В AuthServiceProvider прописываем правила. Типа

Gate::define('CREATE_PRODUCT', function($user){
          return $user->canDo(3);
        });

На каждый пермишен или автоматизировать.

В модели User делаем проверку

public function canDo($perm_id) {
      foreach ($this->roles as $role) {
        foreach ($role->perms as $perm) {
          if ($perm_id==$perm->id) {
            return true; }}}}

Теперь подключив Gate к контроллеру можно делать перед выполнением метода.

if (Gate::denies('CREATE_PRODUCT ')) {
               abort(404);
             }

И в шаблоне

@can ('CREATE_PRODUCT’)
Код создания продукта
@endcan

Все. Можно ограничить еще в роутах (через мидделварь, эт о просто). Что там еще? Назначать роли в контроллерах просто. Типа

If($user->isDirector() and $company->type(‘it’))
{
$user->roles()->attach($id);
}

Attach делает запись в промежуточной таблице
Type – метод у компаний, который ищет по массиву типов
isDirector - метод у юзера типа

public function isDirector()
{
if роль == director return true;
return false;
}

Или получать роль через имя

public function getRole($name)
    {
        return $this->roles()->where('name', $name);
    }

Но лучше (для меня) создать дату с ролями в модели User (типа констант) и искать по id, а не по name(я так сделал)

Что касается разных ролей для каждой компании. Можно связать компании роли и юзеры и получать права записью типа
$user->company($id)->roles();

Да-да валидация в отдельных файлах очень удобна
php artisan make:request FileRequest
и туда перенести правила и сообщения, а в контроллере подключить его через use и использовать в методе (FileRequest $request). Остальной код супер)) Можно еще добавить проверок переменных например if($relation)... и т.д. для исключения ошибок, добавить также права доступа к методу ну и конечно подключить выгрузку json для js

Если в отношения пока не вникнуть, то есть максимально простой способ:
1)В таблице tasks создать столбик user_id. Его желательно связать с users, но на начальных этапах лучше не забивать голову такими мелочами)) Все равно потом 10 раз потом все переделывать, сносить таблицы, все переименовывать, переписывать и т.д.
2) Когда создаете task записываете в user_id =Auth::id();.

$task=new Task;
$task->user_id = Auth::id();
$task->save();

Зачем это? Чтобы получить id авторизованного в данный момент пользователя и тем самым прописать, что типа задача принадлежит ему.
При этом нужно не забыть подключить фасад auth( use Auth в шапке контроллера над названием класса);
3) Все задача привязана. Теперь нужно получить их.

$tasks=Task::where('user_id',Auth::id())
                                      ->get();

теперь в переменной $tasks будут задачи авторизованного в данный момент пользователя.
4) Вам наверняка захочется их отсортировать, подсчитать количество и сделать пагинацию.
Поэтому можно будет прописать

$tasks=Task::where('user_id',Auth::id());
$count = $tasks->count();
$tasks=$tasks->orderBy('updated_at', 'desc')
                      ->paginate(20);

Это задачи пользователя с сортировкой по дате изменения, количеством и по 20 записей на страницу.
Ларавель пагинацию сделает автоматом. Вам нужно будет только разместить в шаблоне.
{{ $tasks->links() }}
Все можно запускать в продакшен