Feature wanted: ability to store multiple fields into one database attribute

Bug report

What I did

Use 2 table fields type to store each time one item with simple key/value values, in a single settings Model attribute (json field on db side). Set ˋmax` to 1 to allow only one row on for each.

For example :

[   // Table
    'name'            => 'options_a',
    'label'           => 'Options A',
    'type'            => 'table',
    'entity_singular' => 'option À ', // used on the "Add X" button
    'columns'         => [
        'name'  => 'Name',
        'desc'  => 'Description',
        'price' => 'Price'
    ],
    'max' => 1,/ maximum rows allowed in the table
    'min' => 0, // minimum rows allowed in the table,
    'fake' => true,
    'store_in' => 'settings'
]

[   // Table
    'name'            => 'options_b',
    'label'           => 'Options B',
    'type'            => 'table',
    'entity_singular' => 'option B ', // used on the "Add X" button
    'columns'         => [
        'foo'  => 'Foo',
        'bar'  => 'Bar',
    ],
    'max' => 1,/ maximum rows allowed in the table
    'min' => 0, // minimum rows allowed in the table,
    'fake' => true,
    'store_in' => 'settings'
]

What I expected to happen

Stored value in simple JSON object

{
  "options_a":{"name":"Rubber", "description":"lorem","price":15},
  "options_b": { "foo":"Ipsum","bar":"dolor"}
}

What happened

Stored each value as array

{
  "options_a":[{"name":"Rubber", "description":"lorem","price":15}],
  "options_b": [{ "foo":"Ipsum","bar":"dolor"}]
}

Also No “add XX” input must be displayed

What I’ve already tried to fix it

As the main goal of using table in this situation is have a cleaner UI/UX without any blade custom I looked for fieldset support but only dirty solutions was found, even in #3283. Grouping fields is a must have when creating a lot a fields form, without requiring custom templating.

I didn’t find where values as casted to array but if I manually update json in DB, then backpack cannot proper reload value in table cells when editing the entry using UI.

single row table mean we want to store flat value, not array value

Is it a bug in the latest version of Backpack?

yes, 4.1

Backpack, Laravel, PHP, DB version

When I run php artisan backpack:version the output is:

[pxpm]

Hey guys! 🌞

I just have one question:

• if you don’t need a table, why use a table ?

I mean, don’t get me wrong, but from the table you are just using the “interface”. It’s not just the “Add” button, you have “reorder” buttons to re-order a single element too. Does it make sense at all? Why not setup the fields directly ??

CRUD::field('table_1_header')->type('custom_html')->value('<h3>Header for my fields all in the same row</h3>');
CRUD::field('table1_field1')->type('text')->wrapper(['class' => 'col-md-4'])->fake(true);
CRUD::field('table1_field2')->type('text')->wrapper(['class' => 'col-md-4'])->fake(true);

CRUD::field('table_2_header')->type('custom_html')->value('<h3>Header for my fields all in the same row</h3>');
CRUD::field('table2_field1')->type('text')->wrapper(['class' => 'col-md-4'])->fake(true);

You will endup with this in your database: {"table1_field1":"hey","table1_field2":"oi","table2_field1":"sup ","table2_field2":"dup"}

Is there any problem using them like this @rroblik that I am missing ??

Thanks for the feedback, Pedro

[pxpm]

Hey @rroblik thanks for the feedback, I don’t like it much either, but I convinced myself that the field is custom_html and it is what it is, a custom html field… it works to don’t worry much about it and usually gets the job done 🙃

You can also split the ci_settings in the three columns you need in the database so each one stores the corresponding values and use an acessor for ci_settings model attribute, adding it to $appends. That way you would still call $model->ci_settings and get the result of your acessor where you combine the three other model attributes in the array form you need.

Or … keep everything inside the same column as I said first and use the acessor / appends technique to return the results parsed the way you need them.

It also seems reasonable to me that a custom field like table_from_array, a sligth variation of the table field (strip the add more, orders etc) and could go something along this lines:

CRUD::field('db_column')->type('table_from_array')->structure(
    [
        'table_1' => [
            'fields' => [
                [
                    'name' => 'table1_field1'
                ],
                [
                    'name' => 'table1_field1'
                ],
            ],
            'label' => 'table 1 title',
        ],
        'table_2' => [
            'fields' => [
                [
                    'name' => 'table2_field2'
                ],
                [
                    'name' => 'table2_field2'
                ],
            ],
            'label' => 'table 2 title',
        ],
    ]
)

Where the tables would be the keys and fields the values to save in the db. Note that in table field you can only use text fields, while in repeatable https://backpackforlaravel.com/docs/4.1/crud-fields#repeatable-1 you can use almost all crud fields, so take that into consideration if you endup choosing one to start working as base.

Best, Pedro