Create a TableField (OSOE-583)

[sarahelsaig]

It would be nice to have a field for storing admin-editable static tabular data.

• The content field settings would let you set the column count, column names (maybe even the types?)
• The editor would use <icbin-datatable> so rows can be added and the content set.
• It could have separate display types for either responsive Bootstrap table or DataTables table.

Jira issue

[Piedone]

Can you provide some example use-cases?

[sarahelsaig]

Could be just for display, or other features could use the data, eg https://teams.microsoft.com/l/message/19:RP9WiT_LDnu29Jh1LFhv4HyRzFipApkrZ5raNoqa2XE1@thread.tacv2/1677989149843?groupId=206263f6-3214-47ba-b3e6-234a95f304cd

[Piedone]

Please elaborate here so it's publicly available.

[sarahelsaig]

The scenario is that we have an OrchardCore.Commerce webshop and we want to add a line item to the cart that represents shipping cost. Instead of some extremely specific implementation that would be hard to customize later, I want to add a workflow trigger for when the shopping cart is loaded. This way the admin can write a JS script to insert the new line item or do any other manipulation on the cart. In the workflow you'd use the Retrieve Content task to load in the content item with the table part and use its data in the script. At the same time you could display the same content item on the site for the end user's information and it won't ever be out of date because you display the same content that the workflow logic uses

[Piedone]

Doesn't this need an extension of the OCC cart instead of a generic table?

Also, any other scenarios where this would be useful?

[sarahelsaig]

Doesn't this need an extension of the OCC cart instead of a generic table?

Nope, the data would be consumed by a workflow triggered by the cart, but it wouldn't belong to the cart. I deliberately don't want us to implement a specific shipping data model in the OCC cart, because the model structure and the calculation logic varies from business to business. For example we were asked about additional shipping costs based on postal code, but in the past I had to address the same feautre in a project where it was based on country code instead of postal code:

Technically you could store this data in the workflow, for example as a JS object array. But that sounds very unpleasant, error prone, and not good for maintenance.

Also, any other scenarios where this would be useful?

Back when I implemented the site setting editor for the locally maintained tax rates feature feature in OCC, I wouldn't have had to write a custom Vue-based editor if this existed.

So to sum it up in general terms:

• Displaying static tables in content items without the need to write HTML or JS.
• Store tabular data that can be consumed in workflows.
• A reusable table editor with a consistent look for any future features that need one.

[Piedone]

Interesting, OK, thanks.

Just to add, we should have the table responsive, of course.