1. Mikhail Korobov
  2. django-widget-tweaks
  3. Issues
Issue #9 resolved

Allow error_css_class and required_css_class to be set universally through settings file

Trey Hunner
created an issue

I frequently want to render fields individually and add an error class conditionally on every field in my form that has an error (so the fields will turn red due to my stylesheets).

I am considering implementing the following features to resolve this issue:

  1. A setting that when enabled adds error_css_class to the class attribute of every erroneous field rendered via render_field (setting called WIDGET_TWEAKS_ADD_ERROR_CLASS maybe?)
  2. A setting that allows a default value for the error class when rendering a field via render_field and error_css_class is not set on the form (setting called WIDGET_TWEAKS_DEFAULT_ERROR_CLASS maybe?)
  3. The same as 1 but with required_css_class
  4. The same as 2 but with required_css_class

I'd appreciate any thoughts on whether this might be a useful feature for widget_tweaks and if this seems like a wise approach to this problem.

Comments (8)

  1. Mikhail Korobov repo owner

    This feature seems useful, and I don't have any practical arguments against it.

    But I'm not wild about putting CSS class names to settings.py - such abstraction leaks is exactly the issue django-widget-tweaks is trying to solve.

    Another option is to implement {% errorcss "error" %}{% enderrorcss %} block tag (ideas about less crazy names are welcome). This tag may set a template context variable which {% render_field %} tag will be taking into account.

    The next question is why only error css class can be set this way? Maybe we need a block tag for configuring {% render_field %} rendering?

    This brings it quite close to {% formconfig %} tag from https://github.com/SmileyChris/django-forms by the way.

    Currently I'm -1 on adding a settings.py variable and +0 for adding block tag for tweaking the output of {% render_field %}.

    We may put it into a separate package "django-widget-tweaks-tweaks".

    What do you think you think?

  2. Trey Hunner reporter

    I tend to use the same JavaScript/CSS form validation framework throughout my entire website when creating a Django project. I suggested a settings tweak for this reason. I agree that the settings solution unecessarily couples settings to the render_field tag.

    So long as {% errorcss "error" %} {% enderrorcss %} would work via includes (so I could use it in my base.html file which I extend all other templates from) I think this would be a more suitable solution. It also seems like these should be nestable (like {% with X=Y %} {% endwith %} is).

    I'm not opposed to creating a tag to tweak the render_field behavior. I think it should also use context variables for configuration though so the settings will only work when enclosed in a configuration tag (like the errorcss idea). What would this tag do (besides allow the error class to be set)?

    How would we implement this in a separate package? Wouldn't we still need to change code in the render_field tag implementation to get it to check BoundedField.errors to append the proper error class?

    I actually have a package called django-widget-tweaks-extras that currently includes miscellaneous render_field-like tags for special fields/widgets that didn't work normally (it's not public currently).

  3. Mikhail Korobov repo owner

    django-widget-tweaks-tweaks was a poor joke :)

    Simple assignment tag should work fine with includes as far as I can tell. It will be limited to "current block" scope - this also feels quite natural. If you put ``{% error_css "cls1" %} in top-level block it should apply globally; there is also would be an option to override it just for the current block. It seems there is no need for {% enderrorcss %} block: django's standard assignment tags don't have {% end.. %} counterparts because their scope is already limited to a current block and this usually make sense.

    I don't really know what form arguments should be tweaked. But with issue #8 resolved it seems natural to have a single {% render_field_options %} tag that accepts exactly the same options as {% render_field %}.

  4. Trey Hunner reporter

    I thought Django's assignment tags did have end blocks so that they could be nested.

    For example:

    {% with variable=value1 %}
        {{ variable }} == value1
        {% with variable=value2 %}
            {{ variable }} == value2
        {% endwith %}
        {{ variable == value1 }}
    {% endwith %}

    What would {% render_field_options %} do with the arguments that {% render_field %} accepts? I can't imagine assigning an argument on every field within a template block being useful very often (especially since text fields, checkboxes and radio buttons are often given different arguments).

    I do want to make django-widget-tweaks-extras public, but I need to clean it up first. It currently contains hack workarounds and lacks tests.

  5. Mikhail Korobov repo owner

    I was talking about these assignment tags. But indeed the presence of {% with %} tag makes writing custom tags not necessary.

    What about simply this?

    <form action=""> {% csrf_token %}
    {% with WIDGET_ERROR_CLASS='error' WIDGET_REQUIRED_CLASS='required' %}
        {% render_field form.field %}
    {% endwith %}

    This way it would be easy to turn some class on globally by using context processors.

  6. Trey Hunner reporter

    I think that's a reasonable implementation. The feature will be straightforward to understand that way and the code changes required will be minimal. Let's do it that way.

  7. Log in to comment