www/caddy: partials bootgrid example implementation

[Monviech]

This PR is not for merging but rather for discussion of the code.

It aims to generalize the bootgrid table setup.

If this approach seems valuable, I would like to add it to core in some way.

Current status: "Works for me"

[fichtner]

A bit too much boilerplate for my taste, but I'm sure this can be improved. Can't the form hold the additional argument too?

[Monviech]

My main issue here was this:

plugins/www/caddy/src/opnsense/mvc/app/views/OPNsense/Caddy/reverse_proxy.volt

Line 353 in dbe996b

<th data-column-id="enabled" data-width="6em" data-type="boolean" data-formatter="rowtoggle">{{ lang._('Enabled') }}</th>

data-column-id="enabled"

plugins/www/caddy/src/opnsense/mvc/app/controllers/OPNsense/Caddy/forms/dialogReverseProxy.xml

Line 3 in dbe996b

<id>reverse.enabled</id>

<id>reverse.enabled</id>

I need to split the id. I could not process that in the template due to restrictions.

Maybe this boilerplate can be centralized at a different spot so I can always receive a data-column-id that has been generated from the id.

[fichtner]

symbolic approval here, I think the approach is very nice 👍

a few design decisions regarding form xml need to be made but that's just optics

[Monviech]

This here has the side effect to also change the order in the form dialogue. If there should be a /different/ sequence for the columns and the form this solution has to be changed.

[Monviech]

When I tried to do it like this in the .volt template it always crashed. So there are very different possibilities between volt and jinja 2 it seems and I can not sort the same way in the template as e.g.: here:

plugins/www/caddy/src/opnsense/service/templates/OPNsense/Caddy/includeLayer4

Lines 15 to 23 in dbe996b

	{% set unsorted_layer4_configs = helpers.toList('Pischem.caddy.reverseproxy.layer4') %}
	{# Ensure that 'Sequence' is present and converted to an integer in each item #}
	{% for item in unsorted_layer4_configs %}
	{% set _ = item.update({'Sequence': item.get('Sequence', '0') | int}) %}
	{% endfor %}
	{# Sort the configurations based on 'Sequence' #}
	{% set layer4_configs = unsorted_layer4_configs | sort(attribute='Sequence') %}

[AdSchellevis]

I was doubting a bit to offer feedback in the code, but it's probably easier to document my comments and concerns here.

Although I don't mind combining grid fields in forms, we do need to seek a way to explain the fields properly and prevent cluttering functionality.

Consider the following field (which my the way could also be positioned in a [sub]tab)

    <field>
        <id>subnet4.description</id>
        <label>Description</label>
        <type>text</type>
        <help>You may enter a description here for your reference (not parsed).</help>
    </field>

If we add a sequence field here, what does it mean?

So how about positioning the grid properties inside a container, e.g.

    <field>
        <id>subnet4.description</id>
        <label>Description</label>
        <type>text</type>
        <help>You may enter a description here for your reference (not parsed).</help>
        <grid_view>
            <sequence>1</sequence>
        </grid_view>
    </field>

My next issue is more or less a past sin, as getForm() returns a plain list, its difficult to add information for multiple targets (roles). We can use getForm() to extract, but then still need to interpret the results. Which pleads for a separate function to extract the grid[s] from the form definition.

Maybe if we add a getFormGrids() it would be easier to understand the code. My assumption would be that the id identifies the path, we should be able to recursively extract a structure like the following from the definition above:

{
    'subnet4': {
          '0000001.0001': {
               'id': 'description',
                'description': 'Description',
                .....
           }
    }
}

The 0000001.0001 we would generate based on the row number of the record (second part) and the offered sequence for the field.
We can then easily sort all found containers by key.

Obviously we need to feed the output of getFormGrids() to the view in the same way as we would for the form (which means we pass two containers).

I can take a look at building the getFormGrids() method, but not today I'm afraid, maybe it's better to start with a ticket in core if we wish to pursue this further. The idea is practical, I think the bootgrid_tables partial is more or less ok (just needs to be named bootgrid_table as it generates one). There are just details to be filled in at some point (for example how to map types and suppress fields when not relevant at all)