CRUD контроллер

[boxfrommars]

Так как мы, похоже, определились с роутингом (стандартный resource), то пора взяться за базовый CRUD контроллер для админки.

Существующие решения в наших проектах

CompassPools, Axis Big

CrudController

использование: 1 2

Адекватный CRUD, но я не нашёл в проекте его "чистого" использования, нужно понять с чем это связано и постараться избежать такого

Awi, Neometria

AbstractCrudController
CrudController > AbstractCrudController
RestController > AbstractCrudController

Использование: 1 2

Не очень удачная работа с видами (контроллер сам засовывает вид в лайаут), очень много жонглирования с именем ресурса (часто приводим к camel_case и всё такое)

[boxfrommars]

Вот описание CRUD от scotch.io. Тут не делается общий класс, а рассматривается на примере, но всё становится понятно. Ещё минус, что это для 4 версии

[boxfrommars]

все примеры CRUD выше основаны на том, что у контроллера есть свойство $name на основе которого мы по соглашению генерируем имена роутов, видов, определяем модель которой пользуемся. Но есть другой подход -- генерация контроллеров, когда пишется команда, выполнение которой генерирует файл контроллера с нужными нам видами.ю роутами и т.д. Как пример такого генератора: appzcoder/crud-generator. Темплейт для контроллера выглядит так: https://github.com/appzcoder/crud-generator/blob/1.0/src/stubs/controller.stub.

Генераторы это хороший подход, но мне кажется мы можем скомбинировать оба подхода, чтобы сгенерированный файл не был бы таким большим.

[boxfrommars]

я сделал пример crud-контроллера на основе используемых нами сейчас: https://github.com/Rutorika/laravel-dashboard/blob/master/app/Http/Controllers/Dashboard/ResourceControllerA.php

предлагаю обсудить. если есть свой вариант, который выготовы предложить, то клонируйте, пишите рядом свой контроллер (я назвал свой ResourceControllerA, то есть можно пользовать остальные буквы алфавита:) их обсудим тоже. желательно (но не обязательно), чтобы он работал с теми же видами и поддерживал:

• пагинацию
• родительскую сущность
• валидацию

так же нужно обсудить ajax-вариант (будет ли он отдельный или мы просто будем проверять тип запроса и в зависимости от него или возвращать вид/редирект или json)

[boxfrommars]

я удалил пример из предыдущего каммента (он был сырой), и чуть изменённым использовал здесь: https://bitbucket.org/rutorika/space/src/c5952f3c41fbd81c63c6adf5dc7d09e1aa6fc782/app/Http/Controllers/Dashboard/CrudController.php?at=master&fileviewer=file-view-default

минусы:

1. мне не нравится получение параметров запроса:

return $this->getRouter()->current()->getParameter($name);

приходится получать именно так, потому что для resource-роутов необходимо в параметрах действия указывать правильное имя переменной, если, например:

Route::resource('article', ArticleController)

то действие должно быть таким (прямо укзываем $article)

public function show($article) 
{
...
}

может быть стоит сделать действия абстрактными методами и описывать их уже в наследнике? надо проверить, как будет прощё выглядеть результат.
2. мне не нравятся свитчи для получения видв, редиректов и рулсов, опять же возможно это нужно решать уже на уровне контроллера наследника (это снова увеличивает размер наследника)
3. просто слишком большим получился круд, это тоже добавляет сомнений в его правильности

[demidovich]

@boxfrommars Димыч, если взять за прототип твой crud, но:

1. Для админки не использовать ресурсы, а оставить стандартный роутинг. Что страшного в том, что файл routes.php будет немного раздут?
2. Мелкие упрощения. Например, мне кажется наличие publish и unpublish избыточно, достаточно одного publish, который будет переключать флаг (в видах будет проще, соответственно). Но это фигня и мелочь.
3. Для всех (не action) методов, используемых в crudController использовать префикс, например crud. Это будет упрощать работу с модификацией и перезаписью методов в конечных контроллерах. Будет видно, что перезаписывается.