coralnet icon indicating copy to clipboard operation
coralnet copied to clipboard

Clean up form rendering

Open StephenChan opened this issue 3 years ago • 0 comments

This is a gradual effort that I've started for a few forms in PR #439, and hope to stretch out to almost all the forms on the site before too long.

  1. I previously haven't been a big fan of Django's whole-form rendering functionality, such as {{ my_form }} or {{ my_form.as_p }}, because customizing it would've involved writing a lot of HTML directly in Python. However, starting in Django 4.0, customization would instead involve overriding HTML templates such as django/forms/default.html or django/forms/p.html. It can be a custom template per Form subclass, too. IMO this makes it more worth the effort to make whole-form rendering work. I think our form page templates will be cleaner if we use this rendering system, rather than our old ways of going like this (for each individual form):

         {% for field in my_form %}
             {% include "form_generic_one_field.html" with field=field %}
         {% endfor %}
    

    Or like:

         {% include "form_generic_one_field.html" with field=metadata_form.name %}
         {% include "form_generic_one_field.html" with field=metadata_form.height_in_cm %}
         {% include "form_generic_one_field.html" with field=metadata_form.latitude %}
         ...
    

    Or like:

     {{ form.photo_date.label }}: {{ form.photo_date }}
     {{ form.image_name.label }}: {{ form.image_name }}
    

    There is {% include 'form_generic.html' with form=my_form %} which is better, but form_generic.html itself has some clunky aspects, and making minor modifications to it at this point has a danger of breaking various forms unexpectedly. I've opted to start from a fresh template to make the overhaul easier to roll out gradually.

    We aren't on Django 4.0 yet, so for the time being I've set it up so that we can go like {% include 'django/forms/default.html' with form=my_form %} instead of {{ my_form }}. Then when we get onto 4.0, making the switch should be relatively simple.

  2. The CSS for rendering forms has been clunky/convoluted. I've made small efforts to clean up the CSS before, but it just made us end up with several forms that were hacky/inconsistent relative to other forms on the site. I'm hoping to get it right this time, with the help of more modern constructs like CSS Grid. Another thing I'm trying to do now is make the new styling independent of the old styling, so it can stand alone rather than being designed to sit on top of the old styling - that makes it easier to reason about. The new styling currently lives in lib/static/css/forms.css. I think it's better for form styling to go into its own file, rather than putting almost everything in a master.css.

StephenChan avatar Feb 24 '22 23:02 StephenChan