OpenEnergyPlatform / django-comparison-dashboard

Django app holding functionalities for comparing scenarios
MIT License
1 stars 0 forks source link

save chosen scenarios and filter settings #8

Closed josihoppe closed 9 months ago

josihoppe commented 10 months ago
henhuy commented 9 months ago

Found an error if settings are stored twice under same name. Loading data from model via get (https://github.com/OpenEnergyPlatform/django-comparison-dashboard/blob/6fb07f50d7edb76eb0cdf0860ce538fab80975e4/django_comparison_dashboard/views.py#L133) fails. Best solution would be to check input field, while entering value (onchange event) and give feedback to user if name is already used. See example at https://htmx.org/examples/inline-validation/ Additionally, model field name should be marked unique.

henhuy commented 9 months ago

Another error I found: I could not save settings due to input error in field facet_col (did not set a required value), but no error was thrown, or input field has not been marked as invalid. To address this, I added a CSS styling which marks invalid fields. See https://github.com/sedos-project/sedos_dashboard/blob/ae3512f3feaaec555fb25b79aa576df062007a75/sedos_dashboard/static/css/project.css#L15 Additionally, an error message should be shown next to save button to inform user. This could be done by using JS or hyperscript (already added to sources) on htmx:validation:failed event, see https://htmx.org/docs/#validation

henhuy commented 9 months ago

To prevent error on loading settings due to a name which is not present in DB, instead of using a text field at loading form, we should switch to dropdown menu with all possible filter setting names. This dropdown menu must be updating then, in case of adding filter settings by save form.

henhuy commented 9 months ago

I fixed loading of filter settings by requesting the whole page when loading filter settings (instead of HTMX request)

josihoppe commented 9 months ago

To prevent error on loading settings due to a name which is not present in DB, instead of using a text field at loading form, we should switch to dropdown menu with all possible filter setting names. This dropdown menu must be updating then, in case of adding filter settings by save form.

I modified the form in the dashboard.html so that the already saved filter-settings name are used as values and if something new is saved only the load-form is refreshed with the new value.

josihoppe commented 9 months ago

Found an error if settings are stored twice under same name. Loading data from model via get (

https://github.com/OpenEnergyPlatform/django-comparison-dashboard/blob/6fb07f50d7edb76eb0cdf0860ce538fab80975e4/django_comparison_dashboard/views.py#L133 ) fails. Best solution would be to check input field, while entering value (onchange event) and give feedback to user if name is already used. See example at https://htmx.org/examples/inline-validation/ Additionally, model field name should be marked unique.

Model field is now markes unique and there is inline validation added to check that the filter settings name is not empty or already taken. Also the save function throws an error now in these cases.

But after these changes I encountered an error when trying to save: django_comparison_dashboard/forms.py", line 205, in cleaned_data data |= form.cleaned_data AttributeError: 'ColorForm' object has no attribute 'cleaned_data'

josihoppe commented 9 months ago

Another error I found: I could not save settings due to input error in field facet_col (did not set a required value), but no error was thrown, or input field has not been marked as invalid. To address this, I added a CSS styling which marks invalid fields. See https://github.com/sedos-project/sedos_dashboard/blob/ae3512f3feaaec555fb25b79aa576df062007a75/sedos_dashboard/static/css/project.css#L15 Additionally, an error message should be shown next to save button to inform user. This could be done by using JS or hyperscript (already added to sources) on htmx:validation:failed event, see https://htmx.org/docs/#validation

the validation when saving the filter Settings is processed on the server-side. The error messages are handled as htmx requests. But doing this the unit-form was causing trouble because it always seems to be validated as invalid.