#5 Merged
Repository
Deleted repository
Branch
default (5cb3b29493ac)
Repository
kmike/django-widget-tweaks django-widget-tweaks
Branch
default

Add render_field support for error/required class

Author
  1. Trey Hunner avatarTrey Hunner
Reviewers
Description

This is an implementation for the feature discussed in issue #9.

Comments (8)

  1. Trey Hunner author

    I thought about adding the feature for template filters, but I wasn't sure how that should be implemented.

    Which filters do you think should check for these variables and add classes? And in what cases?

    Should this filter usage add the appropriate error/required classes?

    {{ form.search_query|attr:"type:search" }}
    

    It seems a little odd that if not using render_field you must touch the field with a filter to coax the correct error/required classes out of it. Maybe there should also be a with_special_classes filter (probably with a more appropriate name) that simple adds those classes when necessary? That filter could be called by all or most other filters in addition to being used by render_field.

  2. Trey Hunner author

    I agree :-)

    Maybe the docs should explain that there are really two primary ways to use django-widget-tweaks:

    1. Use the filters as needed for one-off changes
    2. Go all out and use render_field for everything
  3. Mikhail Korobov repo owner

    Filters are useful because they are more flexible. See "reusable field template" example in docs - we define a field template and override some of the attributes later, when this template is included - this is not possible without filters.

    render_field also currently lacks support for add_error_attr.

    For other use cases (including one-off changes) I tend to prefer {% render_field %}. So IMHO the easiest way to work with django-widget-tweaks is "go all out and use render_field for everything; filters are here if you need extra power".

    So I'd be happy to merge a pull request with docs changed in that vein :)

  4. Trey Hunner author

    I'll think about this change some and make a pull request if I think of a good way to explain the difference.

    I see what you mean with filters being more flexible. It could be useful to generalize render_field more so that it supports add_error_attr and extensions in the same vein as the "reusable template field" example in the docs.

    I wonder whether supporting this syntax would be useful: {% render_field form.field|add_error_attr type="date" %}

  5. Mikhail Korobov repo owner

    I think something like #7 might solve the issue with render_field flexibility.

    As for add_error_attr - create an another template variable (WIDGET_ERROR_ATTR), there is no need to make render_field syntax more complex.

Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.