Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
burnout87 opened this issue Oct 31, 2024 · 4 comments · May be fixed by #58 or oda-hub/mmoda-frontend-module#279
Open

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

burnout87 opened this issue Oct 31, 2024 · 4 comments · May be fixed by #58 or oda-hub/mmoda-frontend-module#279
Assignees
Labels

Comments

@burnout87
Copy link
Contributor

Advances Domain

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

  • UX
  • resilience
  • community-expanding feature
@burnout87 burnout87 self-assigned this Oct 31, 2024
@burnout87 burnout87 changed the title New type Filter with text bar for column and error column as text input New type Filter table: column and error column as text input Nov 5, 2024
@burnout87 burnout87 linked a pull request Nov 5, 2024 that will close this issue
@burnout87
Copy link
Contributor Author

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
Copy link
Contributor Author

requires an adaptation on the frontend module as well oda-hub/mmoda-frontend-module#279

@burnout87
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment