Open twiro opened 3 weeks ago
As it would also be useful to offer the opportunity to have translated column names for multilingual setups using the syntax of predefined options actually might be the better choice for the blueprints:
fields:
table:
type: table
label: Table with predefined columns
columns:
column_a: Column A
column_b: Column B
column_c: Column C
fields:
table:
type: table
label: Table with predefined columns (translated)
columns:
column_a:
en: Column A
de: Spalte A
column_b:
en: Column B
de: Spalte B
column_c:
en: Column C
de: Spalte C
In my current project I use the table field as a kind of easier accessible replacement for the structure field, where every table column equals a single field in the structure field and every table row equals a single structure field entry.
In this scenario it would be super helpful, if the editors could only edit the table rows, but not the table columns/headers as editing, adding or changing headers/columns would actually break the expected data structure.
In the table blueprint a feature like this could be solved by a new
columns
-property that would accept an array of column names:This setting would predefine the amount and header-titles of the columns, so no need to add additional column settings like
maxColumns: 3
orminColumns: 3
.Regarding sorting, I would also love to have sortable rows but non-sortable columns in my use case, but it might be a more flexible solution if predefined columns wouldn't be automatically set to be non-sortable, but if the sorting property would simply become more flexible – this could be achieved by adding the following values to the
sortable
-property:I think with these additions the table field would become a lot more flexible and could be considered as a solution for quite some scenarios that can only be handled properly by the structure field (or subpages) at the moment.