[DevTools] Pre-defined column types

[eleven59]

Feature Request

What's the feature you think DevTools should have?

Pre-defined column types and groups of columns for stuff like SoftDeletes and Backpack's own ReOrder functionality. That way users could just tick the boxes for those, instead of having to completely enter all fields manually (possibly making errors). I find myself inputting especially the parent_id, lft, rgt and depth fields manually now, which is quite cumbersome.

For Reorder, it would be great if that would auto-detect to include that operation in the model, and add the setupReorderOperation function, too. Perhaps auto-detect the first "string" column for the reorder label?

It would also be really cool if such groups could be defined somewhere (config file, or also part of DevTools) so custom groups of predefined columns could also be added to this list.

Mock-up:

Have you already implemented a prototype solution, for your own project?

No.

Do you see this as a core feature or an add-on?

Core feature.

[pxpm]

Hello @eleven59 thanks for the feedback!!

I like the idea of those aliases, as so we already implemented some, like SoftDeletes, Morphs. If you select SoftDeletes column type you will the get correct column in the migration and the use Illuminate\Database\Eloquent\SoftDeletes; is automatically added. Like if you select morphs, it would create the correct morph columns in the database.

It would be insteresting to have something that generates those parent_id, lft, rgt columns, maybe a NestedSet (i think it's how those are called) column type that generates the columns for a nested set ?

Food for tougth, I just wanted to write it so I don't forget I thinked about it! 👍

Thanks again @eleven59 !

Best, Pedro

[eleven59]

Ah, thank you! I totally missed the SoftDeletes option. Makes a lot of sense to have it as a column type choice, too. Using NestedSet for more complex combinations also makes sense. Looking forward to any updates that include more stuff like this, but I'm already liking the DevTools very much!

[promatik]

@eleven59 this is a great idea!

I'll describe how I see this as a great feature.

We could add a section on config for these nested sets, reorder would be there, and it would be our example for the devs to customize it as they need.

'sets' => [
    'Reoder' => [
        'columns' => [
            'parent_id' => ['unsignedBigInteger', 'nullable'],
            'lft' => ['unsignedInteger', 'nullable'],
            'rgt' => ['unsignedInteger', 'nullable'],
            'depth' => ['unsignedInteger', 'nullable'],
        ],
        'traits' => [
            'controller' => ['\Backpack\CRUD\app\Http\Controllers\Operations\ReorderOperation'],
        ],
        ...
    ],
    'Another Set' => ...
],

[tabacitu]

Just dropping in to say I like this feature too. We probably need to make a list with all the stuff we want to make easier. Because for the above, I think it'll be easier using a column type:

• 🟨 add a column type order column (or nested_set or reorder or something like that), then the Controller will just have the Reorder operation automatically;
• 🟨 add a column type slug and the Model will have Cviebrock\Sluggable automatically;
• ✅ add a column type SoftDeletes and the Model will have SoftDeletes automatically;

I think it'd be better to solve the above at the "database definition" stage. Since it also implies some db columns.

Another option to do these kinds of things would be at the "CrudController" stage, which we have NOT implemented yet. Basically after you configure the Migration & Model, to be able to configure the generated CrudController. There, you'd be able to do stuff like:

• 🟨 enable/disable certain Operations;
• 🟨 for the Create Operation, choose the fields and types for each db column (pre-populated, just edit);
• 🟨 for the Update Operation, choose the fields and types for each db column (pre-populated, just edit);
• 🟨 for the List Operation, choose the columns & column types for each db column and activate/deactivate certain ListOperation features;

It's difficult to draw the line there where we should stop helping, though. Some things (like changing a field or column type) will probably break the CrudController... so maybe they're better done in code, by the developer, since they need to go do that anyway... This is the reason we haven't gotten started on this yet...

I still like the features expressed above - thank you for submitting this @eleven59 . Just mentioning where this might take us (or where it might not) to be completely open about it. TLDR:

• adding new column types that do the above - good;
• adding the ability to granularly configure the generated CrudController - might not be as good;

I know I'm the one that suggested that 😅 The irony.