New type Filter table: column and error column as text input

[burnout87]

Advances Domain

Mention the Domain this issue addresses, e.g.:

• UX
• resilience
• community-expanding feature

[burnout87]

Making this adaptation is requiring way more time than anticipated:

the current version of the tab-generator assumes that only one Euclid parameter (eg filters_table inside photo_z ) is present.

When adding a new notebook, with another PhosphorosFiltersTable table, I noticed that the order the parameters over the interface is not preserved, this causes the interface, along with the related logic implemented within the javascript code, to no longer work. This requires more understanding on how to address the issue of the order for which I am working on an implementation with #58, but it's far from optimal, and it might require quite some time.

[burnout87]

requires an adaptation on the frontend module as well https://github.com/oda-hub/mmoda-frontend-module/pull/279

[burnout87]

With this approach, currently used only for the Eculide specific parameters (but to be discussed if to extend it generally), each PhosphorosFiltersTable is associated to the notebook where this is declared. An example can be found in my current photo-z fork, where there are two notebooks, each with a filters_table parameter, (ie same name) but in one case this is not grouped with a catalog_URL parameter (a PosixPATH): first and second.

This results in declaring two filters_table_{{ product_name }} entry in the .inc file, where the multivalued_field_param_name attribute is used then within the frontend JS to build the form of the request.

[burnout87]

Assuming that two PhosphorosFiltersTable are present in two notebooks, and those have different names (filters_table and fitlers_table_new), then it works.

But, if the same name is set, and different extra_metadata are set, then problems start, and the put put is not going to be expected one.

In order to fix this, much more work and refactoring would be needed.