[Feature request] Advanced_table field - which allows to specify field type for each column

[mamprogr]

trafficstars

Hello,

I think it is useful if we are able to specify the type of columns in the table type.

E.g. the price should be number only.

[pxpm]

I think for what you want, the repeatable field in 4.1 branch is perfect. It's still beta, very close to launch (i hope) but you can already use it.

Check it out in demo if it matches your needs: http://demo-beta.backpackforlaravel.com/admin/dummy/create

Going to close this, i don't think we are going to support multiple field types in table field type.

If you feel I am wrong, and be sure that sometime I am, feel free to reopen.

Best,

[tabacitu]

I can confirm we're not working on this right now - like @pxpm said. We're currently knee-deep in bug fixing Backpack 4.1, so we can get it out the door, thank you for understanding @mamprogr .

But 😄

Now that we've made sure all fields work inside repeatable. It should't be too difficult to create a new advanced_table field (or something), that would allow us to do:

[   // Advanced Table
    'name' => 'options',
    'label' => 'Options',
    'type' => 'advanced_table',
    'entity_singular' => 'option', // used on the "Add X" button
    'columns' => [ // aka fields - 'cause that's what they are actually 
        [   // Text
            'name' => 'title',
            'label' => "Title",
            'type' => 'text',
        ],
        [  // Select
           'label' => "Category",
           'type' => 'select',
           'name' => 'category_id', // the db column for the foreign key
           'entity' => 'category', // the method that defines the relationship in your Model
           'attribute' => 'name', // foreign key attribute that is shown to user
        ],
        [   // Checkbox
            'name' => 'active',
            'label' => 'Active',
            'type' => 'checkbox'
        ]
    ],
    'max' => 5, // maximum rows allowed in the table
    'min' => 0, // minimum rows allowed in the table
]

In fact, this sounds awfully familiar with what my initial idea for the matrix field type would be (see Laravel-Backpack/CRUD#131 ). Which turned into the repeatable field type.

Now... the repeatable field type is nice and all. It'll work great for A LOT more use cases, because there's no limit to how many fields to include in one field group. An advanced_table field, however, would be limited - you can't put in more than 3-5 columns, it'll get too big and too difficult to use.

But. I do see myself wanting a repeatable that looks like a table. I personally would prefer this advanced_table field 95% of the time. Because I rarely need more than a few columns inside a complex field like this. For example, for invoice_items - 3-5 columns.

So let's leave this open, tag it as a feature that we maybe create for 4.1.x. It's not a priority, but it'd be cool - personally I'd love it. If anybody else ends up building it, please share - would really appreciate it.

Cheers!

[mamprogr]

Thanks for your helpful reply.

By the way, the + New Item in repeatable is not translated.

[rodrigoUriarte]

What will be the difference between this and the repeatable field? Only the interface change?

[tabacitu]

What will be the difference between this and the repeatable field? Only the interface change?

Yup 😄

[KieranLR]

Ah, I made something like this myself for a project. We also thought repeatable was a better UI as a table! We called it repeatable_grid.

It looks like this

Let me know if you have use for the blade file, or other details. I'd love to help out, although I can't guarantee being able to share anything yet.

[pxpm]

Hey @KieranLR

That really looks neeeeeeeeat 👀 !! Congratulations it seems a pretty nice job!

It would be even awesome if repeatable had a away to simple write: 'display' => 'table' and your repeatable field would be displayed as a table like this but kept the "internals" working for both, what I meant is don't need to code order, delete etc all over again because it's displayed in table mode and not in repeatable mode.

Tables bring other stuff to the "table", one of my major concerns is responsiveness, but yeah, it's probably doable.

If you are willing to share just put it on some gist and share the link here, people will find it when searching and maybe it serves as inspiration to have something like that in core or as a addon.

Thanks, Pedro

[tabacitu]

That. Looks. AWESOME!! 🎉🎉🎉 Great job @KieranLR ! Yes please, the blade file would be super-helpful.

It would be even awesome if repeatable had a away to simple write: 'display' => 'table' and your repeatable field would be displayed as a table like this

@pxpm I... don't agree 😅 That would make it a nightmare to maintain that field... I can only imagine the number of conditionals. Separate fields would be better, I think. If they share some JS... fine, that JS can be a separate file (included by both). But otherwise... no point in merging two interfaces in one field, it would become a mess very very fast.

Tables bring other stuff to the "table", one of my major concerns is responsiveness

Hmmm yeah... good point. I guess this would only make sense for devs that know their Admin Panel will be used mostly from desktop, otherwise... repeatable would be a better solution, since it's also responsive... Good point @pxpm 👏👏👏

[KieranLR]

Thanks for the feedback! Here's the blade file: https://gist.github.com/KieranLR/a6dabc4aa994e56d6d47018618f3cc3f

The field already has the logic to switch between grid, and non-grid mode.

This doesn't mean that splitting them into two blade files isn't a good idea though. Sometimes new features will have different functionality depending on which layout you use, and having all that stuff in one file is messy.

However, if there ends up being two repeatable-like fields, like repeatable_table, and repeatable, there should be some way to have both of those files reference shared javascript code, since changing the layout does not change which js code is run on form submission.

I don't know the best way to share javascript code between two fields. Maybe a blade file called repeatableJs.blade, which has all the js code for repeatable. Then both layouts would import that file. Although that would be the first time a backpack field does something like that, and could introduce some confusion.

As for responsiveness, all I've added is an option to make the table scroll if it's wider than the screen. So mobile users would have to scroll their screen to view all the columns.

There are still quite a few kinks to work out with this. Here are a few issues I haven't found a fix for yet:

• Most fields by default don't actually align properly in the table, unless you change their wrapper class. I've added a class called repeatable-form-group, which works for most, but not all fields.
• Individual field Labels are hidden, and column headers are used instead. This means fields like radio don't have labels on each option anymore.
• Column Width. I used css-grid to maintain the grid structure. However, I found it difficult to automatically determine how wide each column should be. I gave the field option "gridColumns", which allows you to specify how wide each column is. A more intuitive or automatic approach should be used instead.

[tabacitu]

Awesome, thank you so much @KieranLR 🙏 Excellent breakdown of the limitations, too.

We'll take another look at this when putting together the next features - right now we're very very focused on finishing up the features in 4.2, so we can get that out the door.

We'll be back. We super-appreciate the fact you've shared this with everybody. Thanks again!