Feature Request

What I am trying to achieve

Any way to use a custom field, or a field provided by a third-party addon (eg toggle) using this resource syntax... but without having to create a class for it too?

How I see it implemented

Maybe a CustomField object, that would take in not only the field label/name, but also the type?

    CustomField::make('agreed')->type('toggle'),

What I've already tried to fix it

Nada 👀 Just spitballing here.

Would I be able to work on this myself and submit a PR

Sure.

Related Issues

Original Issue: #3

Context and Purposes

In order to further simplify the usage of a CrudResource, the validations rules for the fields should reside in the CrudResource itself and/or to the fields themselves.

Challenges and Solutions

Field-level Validation Rules

In this update, we have added both the above support. Here's an example of using field level validation rules:

public function fields(): array
{
    $id = $this->crud->getRequest()->input('id') ?? $this->crud->getRequest()->route('id');

    return [
        Text::make('Name')
            ->rules('required', 'min:5', 'max:255')
            ->sortable(),

        Email::make('Email')
            ->rules('required')
            ->creationRules('unique:users,email')
            ->updateRules('unique:users,email,'.$id),

        Password::make('Password')
            ->size(6)
            ->rules(['confirmed', 'min:8'])
            ->onlyOnForms(),

        Password::make('Confirm Password', 'password_confirmation')
            ->size(6)
            ->creationRules('required')
            ->onlyOnForms(),
    ];
}

As shown in the example, there are three methods to use:

• rules: adds the validation rule for both create and update forms
• creationRules: adds the validation rule only for create form
• updateRules: adds the validation rule only for update form

Resource-level Validation Rules

In addition to the field-level validation, the validation rules/messages can also be added to the CrudResource itself. Example:

/** @inheritDoc */
public function validationRules(): array
{
    $id = $this->crud->getRequest()->get('id') ?? $this->crud->getRequest()->route('id');

    $rules = [
        'name' => 'required|min:5|max:255',
        'role' => 'required',
    ];

    $rules['email'] = $this->crud->getOperation() === 'create'
        ? 'required|unique:users,email'
        : 'required|unique:users,email,'.$id;

    $rules['password'] = $this->crud->getOperation() === 'create'
        ? 'required|confirmed'
        : 'confirmed';

    return $rules;
}

/** @inheritDoc */
public function validationMessages(): array
{
    return [
        'name.required' => 'You gotta give it a name, man.',
        'name.min' => 'You came up short. Try more than 2 characters.',
    ];
}

Feature Request

What I am trying to achieve

If/after #4 is implemented, this is how a BookCrudController could look like:

<?php

namespace App\Http\Controllers\Admin;

use App\Http\Requests\BookRequest;
use App\CrudResources\BookCrudResource;
use Backpack\CRUD\app\Http\Controllers\CrudController;
use Backpack\CRUD\app\Library\CrudPanel\CrudPanelFacade as CRUD;

/**
 * Class BookCrudController
 * @package App\Http\Controllers\Admin
 * @property-read \Backpack\CRUD\app\Library\CrudPanel\CrudPanel $crud
 */
class BookCrudController extends CrudController
{
    use \Backpack\CRUD\app\Http\Controllers\Operations\ListOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\CreateOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\UpdateOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\DeleteOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\ShowOperation;

    private BookCrudResource $crudResource;

    /**
     * Configure the CrudPanel object. Apply settings to all operations.
     *
     * @return void
     */
    public function setup()
    {
        $this->crudResource = new BookCrudResource();
    }

    /**
     * Define what happens when the List operation is loaded.
     *
     * @see  https://backpackforlaravel.com/docs/crud-operation-list-entries
     * @return void
     */
    protected function setupListOperation()
    {
        $this->crudResource->buildList();
    }

    /**
     * Define what happens when the Create operation is loaded.
     *
     * @see https://backpackforlaravel.com/docs/crud-operation-create
     * @return void
     */
    protected function setupCreateOperation()
    {
        $this->crudResource->buildCreateForm();
    }

    /**
     * Define what happens when the Update operation is loaded.
     *
     * @see https://backpackforlaravel.com/docs/crud-operation-update
     * @return void
     */
    protected function setupUpdateOperation()
    {
        $this->crudResource->buildUpdateForm();
    }
}

What I see there is a lot of methods that don't really need to be there. At least not in the most common scenarios. So what if we make defining the setup methods optional too? What if the CrudController looked more like this:

<?php

namespace App\Http\Controllers\Admin;

use App\Http\Requests\BookRequest;
use App\CrudResources\BookCrudResource;
use Backpack\CRUD\app\Http\Controllers\CrudController;
use Backpack\CRUD\app\Library\CrudPanel\CrudPanelFacade as CRUD;

/**
 * Class BookCrudController
 * @package App\Http\Controllers\Admin
 * @property-read \Backpack\CRUD\app\Library\CrudPanel\CrudPanel $crud
 */
class BookCrudController extends CrudController
{
    use \Backpack\CRUD\app\Http\Controllers\Operations\ListOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\CreateOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\UpdateOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\DeleteOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\ShowOperation;

    private BookCrudResource $crudResource;

    /**
     * Configure the CrudPanel object. Apply settings to all operations.
     *
     * @return void
     */
    public function setup()
    {
        $this->crudResource = new BookCrudResource();
        $this->crudResource->build(); // calls the correct builder for the current operation
    }
}

How I see it implemented

See above.

What I've already tried to fix it

See above.

Would I be able to work on this myself and submit a PR

Sure, before the v6 launch when this is scheduled.

Feature Request

What I am trying to achieve

What if we could define EVERYTHING we need to define for a CRUD, inside the CrudResource? If you prefer to define a CrudResource, I don't really see a reason why you would split your definition across multiple files:

• the CrudController
• the CrudResource
• the CrudRequest (see #3 )

So what if... if you're using CrudRequest... the CrudController is kind of optional? Only there in case you need to do custom stuff, add things to the setup of a particular operation or override how an operation does its thing?

How I see it implemented

To achieve that, we need to move this from the CrudController:

// BookCrudController.php

    public function setup()
    {
-        CRUD::setModel(\App\Models\Book::class);
-        CRUD::setRoute(config('backpack.base.route_prefix') . '/book');
-        CRUD::setEntityNameStrings('book', 'books');
-
        $this->crudResource = new BookCrudResource();
    }

to the CrudResource:

// BookCrudResource.php


class BookCrudResource extends CrudResource
{
    protected $model = \App\Models\Book::class;
    protected $route = config('backpack.base.route_prefix') . '/book';
    protected $entityNameSingular = 'book';
    protected $entityNamePlural = 'books';

    public function fields(): array
    {
        return [
            Text::make('Name')->size(9),
            Number::make('Year')->size(3),
            Textarea::make('Description')->onlyOnForms(),
            Text::make('ISBN'),
        ];
    }
}

But since some of the above will probably not work (see - calling the config 😅), we'll also need setters/getters for the above, so maybe:

// BookCrudResource.php

class BookCrudResource extends CrudResource
{
    protected $model = 'App\Models\Book'; // mandatory
    protected $entityNameSingular = 'book'; // optional, can figure it out from the model name too
    protected $entityNamePlural = 'books'; // optional, can figure it out from the singular too

    // optional
    public function model() 
    {
        return \App\Models\Book::class;
    }

    // optional, would default to using the entity name as URL segment
    public function route() 
    {
        return config('backpack.base.route_prefix') . '/book';
    }

    // optional
    public function entityNameSingular() 
    {
        return 'book';
    }

    // optional
    public function entityNamePlural() 
    {
        return 'books';
    }

    public function fields(): array
    {
        return [
            Text::make('Name')->size(9),
            Number::make('Year')->size(3),
            Textarea::make('Description')->onlyOnForms(),
            Text::make('ISBN'),
        ];
    }
}

What I've already tried to fix it

Nothing, just spitballing.

Would I be able to work on this myself and submit a PR

Sure, before we launch v6.

Feature Request

What I am trying to achieve

It feels a bit odd to me to define the validation rules in a different file, when everything else is defined in the CrudResource.

How I see it implemented

Starting with Backpack v5, we have three ways of adding validation rules, one way being directly on the fields. I see THAT as being the most useful if you're defining a CrudRequest. But I'd also expect to be able to define validationRules() and validationMessages() on the CrudResource... maybe... I don't know...

The end result, to me, could look something like:

class BookCrudResource extends CrudResource
{
    public function fields(): array
    {
        return [
            Text::make('Name')->size(9)->validationRules('required'), // should already work, I think
            Number::make('Year')->size(3)->required(), // alias, todo maybe
            Textarea::make('Description')->onlyOnForms(),
            Text::make('ISBN'),
        ];
    }
}

or like this:

class BookCrudResource extends CrudResource
{
    public function fields(): array
    {
        return [
            Text::make('Name')->size(9)->validationRules('required'), // should already work, I think
            Number::make('Year')->size(3)->required(), // alias, todo maybe
            Textarea::make('Description')->onlyOnForms(),
            Text::make('ISBN'),
        ];
    }

    public function validationRules(): array
    {
        // devs could test the operation here, and do stuff depending on the operation name
        // eg: if ($this->crud->operation == 'update') { change_a_rule(); }

        return [
            'isbn' => 'required|string|unique:books,isbn',
            'name' => 'required|string',
            'description' => 'nullable|string',
            'year' => 'required|integer',
        ];
    }

    // public function validationMessages(): array { return []; }
}

This should clean up the CrudController a bit, so that... ideally, you don't have to do ANYTHING inside the setupXxxOperation() method (more on that in a separate issue).

<?php

namespace App\Http\Controllers\Admin;

use App\Http\Requests\BookRequest;
use App\CrudResources\BookCrudResource;
use Backpack\CRUD\app\Http\Controllers\CrudController;
use Backpack\CRUD\app\Library\CrudPanel\CrudPanelFacade as CRUD;

/**
 * Class BookCrudController
 * @package App\Http\Controllers\Admin
 * @property-read \Backpack\CRUD\app\Library\CrudPanel\CrudPanel $crud
 */
class BookCrudController extends CrudController
{
    use \Backpack\CRUD\app\Http\Controllers\Operations\ListOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\CreateOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\UpdateOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\DeleteOperation;
    use \Backpack\CRUD\app\Http\Controllers\Operations\ShowOperation;

    private BookCrudResource $crudResource;

    /**
     * Configure the CrudPanel object. Apply settings to all operations.
     *
     * @return void
     */
    public function setup()
    {
        CRUD::setModel(\App\Models\Book::class);
        CRUD::setRoute(config('backpack.base.route_prefix') . '/book');
        CRUD::setEntityNameStrings('book', 'books');

        $this->crudResource = new BookCrudResource($this->crud);
    }

    /**
     * Define what happens when the List operation is loaded.
     *
     * @see  https://backpackforlaravel.com/docs/crud-operation-list-entries
     * @return void
     */
    protected function setupListOperation()
    {
        $this->crudResource->buildList();
    }

    /**
     * Define what happens when the Create operation is loaded.
     *
     * @see https://backpackforlaravel.com/docs/crud-operation-create
     * @return void
     */
    protected function setupCreateOperation()
    {
-        CRUD::setValidation(BookRequest::class);
-
        $this->crudResource->buildCreateForm();
    }

    /**
     * Define what happens when the Update operation is loaded.
     *
     * @see https://backpackforlaravel.com/docs/crud-operation-update
     * @return void
     */
    protected function setupUpdateOperation()
    {
-        CRUD::setValidation(BookRequest::class);
-
        $this->crudResource->buildUpdateForm();
    }
}

I noticed this add-on is using fields to also define columns inside the ListOperation. This is probably inspired by Nova, for someone coming from there it should be pretty intuitive, but we should keep in mind that in Backpack fields and columns are separate things, and:

• there might be inconsistencies in the definition, between a field and a column with the same name;
• there will definitely be fields without a corresponding field type;

I don't think this is something that package can fix... it's the inconsistency in Backpack that's the problem. But it's something we should be aware of, test and know.

Let me make this clear, though: we do plan to fix this in Backpack: every inconsistency we can fix in a non-breaking way, we'll do in 5.x, everything else in v6. So... by Backpack v6, this should be a non-issue, we'll have fields and columns perfectly aligned. I'd love for @phpfour to be the one that tracks down and solves these inconsistencies. But there's quite a bit of work to be done there, see https://github.com/Laravel-Backpack/ideas/issues/196 for details.