[Django] #35192: Support injecting custom context into widget templates
Django
------------------------------------------------+------------------------
Reporter: oxan | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Forms | Version: 5.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
The context available to widget templates is currently very rigid and does
not allow any customization. For example, it's currently almost impossible
to add an `invalid` CSS class to widgets that have errors.
I think my preferred solution would be to insert a call to a form renderer
method in the callchain between `BoundField.as_widget()` and
`Widget.render()`, which can be overridden by a custom renderer. It should
receive the `BoundField` itself as an argument so that it has access to
the current state. Something like the following sketch:
{{{#!python
class BoundField:
def as_widget(self, widget=None, attrs=None, only_initial=False):
... # leave current code as-is, except for last call to
widget.render()
return self.form.renderer.render_widget(
field=self,
widget=widget,
name=self.html_initial_name if only_initial else
self.html_name,
value=value,
attrs=attrs,
)
class BaseRenderer:
def render_widget(self, field, widget, name, value, attrs=None):
# this can be overridden to add/change/remove `attrs`, or to
render the widget in an entirely different way
return widget.render(name, value, attrs)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/35192>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Oxan van Leeuwen | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Forms | Version: 5.0
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* cc: David Smith (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: nobody
Cleanup/optimization |
Component: Forms | Version: 5.0
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => needsinfo
Comment:
>it's currently almost impossible to add an invalid CSS class to widgets
that have errors.
I agree that it is currently tricky to add invalid CSS to widgets
(`<inputs>`) and would like to see this eased with Django itself. That was
one of my conclusions when I attempted to write a tailwind styled form
using just Django itself. See
[https://smithdc.uk/blog/2023/bootstrap_form_in_vanilla_django/ blog
post].
I think there's a few different design options here, in addition to your
suggestion above I see a couple of additional options.
- A template filter/tag. This is the approach used by both django-widget-
tweaks and django-crispy-forms.
- Easing use of a custom `BoundField`. Currently you need to override each
field's `get_bound_field()` to achieve this. Maybe this could also be set
on the form renderer? This would also allow folk to make other
customisations such as #35191 without adding a long list of options to the
renderer.
It's probably worth starting a discussion on the django forum to gain
wider views from the community. I'm happy to help with this discussion. As
I think we need a wider discussion on the design I'll mark as 'needsinfo'
for now.
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Forms | Version: 5.0
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
I think a custom `BoundField` could also work indeed. I'm by no means
married to my proposal, it was just the most sensible thing I could come
up with :)
I agree that it could be valuable to have a wider discussion about the
design here, but unfortunately I don't have the bandwidth at the moment to
drive such a discussion.
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Forms | Version: 5.0
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Why was this ticket closed? I think allowing to use a custom `BoundField`
would be a nice enhancement.
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Forms | Version: 5.0
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage:
| Unreviewed
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: nobody
Component: Forms | Version: 5.0
Severity: Normal | Resolution:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Christophe Henry):
* status: closed => new
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner:
Cleanup/optimization | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Christophe Henry):
* owner: nobody => Christophe Henry
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner:
Type: | Christophe Henry
Component: Forms | Version: 5.0
Severity: Normal | Resolution: needsinfo
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* resolution: => needsinfo
* status: assigned => closed
Comment:
Replying to [comment:4 Christophe Henry]:
`BoundField` would be a nice enhancement.
But good news is recently a similar ticket #35521 was raised which lead to
this [https://forum.djangoproject.com/t/proposal-make-it-easy-to-add-css-
classes-to-a-boundfield/32022/3 forum discussion] and your
[https://github.com/django/django/pull/18266 PR] was referenced.
Can you add some of your thoughts into that discussion and see if we can
come to agreement as to what would be the best approach for this?
I will close this ticket while the discussion is in place (this ticket
might not best represent what we decide to progress in the end) but we can
reopen this later if needed 👍
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner:
Type: | Christophe Henry
Severity: Normal | Resolution:
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* resolution: needsinfo =>
* stage: Unreviewed => Accepted
We have a somewhat active discussion on the forum.
The proposal to add `field_css_class` is probably dead in the waters.
Customizing the `BoundField` class is a better proposal since it opens the
door for many customization possibilities in third party projects and
websites, even though it's slightly more complex than #35521.
I'm therefore reopening this ticket and have reviewed the PR somewhat. If
I get some blowback here then that's my fault.
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner:
Type: | Christophe Henry
Component: Forms | Version: 5.0
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* resolution: => needsinfo
* stage: Accepted => Unreviewed
* status: new => closed
Comment:
Replying to [comment:9 Matthias Kestenholz]:
While I agree that the forum post is progressing nicely towards what it
looks a decent consensus, I think it would be wise to wait a few more
posts before re-opening this ticket. I'll add a comment in the thread with
my thoughts and add a reminder to myself to re-check in about a week.
--
Ticket URL: <https://code.djangoproject.com/ticket/35192#comment:10>