[Django] #32523: Warn when trying to use a widget as a field in a form
Django
--------------------------------------------+------------------------
Reporter: Anders Hovmöller | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: 3.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
--------------------------------------------+------------------------
A common mistake beginners make is to import `django.forms.Textarea` and
trying to use that as a Field, even though it's a widget. The result of
doing this is just silence, so it's very difficult for the user to solve
this problem by themselves.
We see this problem often in the Django Discord.
--
Ticket URL: <https://code.djangoproject.com/ticket/32523>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Anders Hovmöller | Owner: nobody
Component: Forms | Version: 3.1
Severity: Normal | Resolution: wontfix
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 Carlton Gibson):
* status: new => closed
* resolution: => wontfix
Comment:
Hi Anders. Thanks for this.
The sentiment here is right I think. More appropriate for a
[https://docs.djangoproject.com/en/3.1/topics/checks/ system check] than a
runtime warning however.
We don't currently have checks for `Form` &co. I'd like to canvas whether
we can come up with enough to make an additional group of checks
worthwhile.
There is a balance between being helpful and adding checks for every
potential mis-use/mis-configuration that we're constantly trying to walk.
Often we say that many checks better belong in user projects. (Adam
Johnson has been writing lots of examples on his blog recently
[https://adamj.eu/tech/2021/02/26/django-check-constraints-prevent-self-
following/ e.g.])
Initially I would create a project level base Form class, implementing the
check, and registering that, plus maybe others. That can either just an
example in a post, or a gist, or such, or else made into the PyPI package.
Then I think canvasing for extra checks that could be considered in the
category. It several come up then a third-party package becomes suitable.
(Visibility plus shared burden of maintenance etc). Then we can look at
whether adding that to core is a good idea, given benefit vs check speed
and maintenance cost, which would go via the DevelopersMailingList (This
sounds like a lot but it's just creating the example base class really.)
In this particular case I'm a little hesitant, as it's not an error that
could be missed — my field just won't be there — vs a configuration error
that might go unnoticed (for which I **want** a check...) — I wonder if we
could find a way to package up a set of checks such that they're just
registered on demand… (I might install them in DEBUG etc.) I haven't seen
anything like that. 🤔
--
Ticket URL: <https://code.djangoproject.com/ticket/32523#comment:1>
Django
Reporter: Anders Hovmöller | Owner: nobody
Component: Forms | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Anders Hovmöller):
> More appropriate for a system check than a runtime warning however.
How would that work? If someone defines a form inside a view function or a
get_form() method, that can't really be checked from a system check right?
> DEBUG
Doing this check in DEBUG mode only makes sense to me. Would you be
willing to accept such a change to the PR?
> There is a balance between being helpful and adding checks for every
potential mis-use/mis-configuration that we're constantly trying to walk.
Well... might I then suggest removing the super slow model verification
the runserver does by default then? :) I am thinking of writing a PR to at
least move that to a different thread or something so it doesn't make
development so slow.
> Often we say that many checks better belong in user projects.
I disagree with that sentiment when it's a common use case that is mostly
hit by beginners who are not competent enough yet to even write such
checks.
Could we maybe have had this discussion before the ticket was closed btw?
It seems strange to do it this way...
--
Ticket URL: <https://code.djangoproject.com/ticket/32523#comment:2>
Django
Reporter: Anders Hovmöller | Owner: nobody
Component: Forms | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
The workflow is pretty standard for OSS project. Discussion happen on the
DevelopersMailingList with the Issue tracker for concrete addressable
items.
This is more or less the only way to keep it maintainable given the volume
of ideas/suggestions/reports.
See the guide on
[https://docs.djangoproject.com/en/3.1/internals/contributing/bugs-and-
features/#requesting-features Requesting features] — it does try to guide
you to the mailing list rather than the issue tracker.
I'm not convinced that a whole new category of checks for forms is worth
the maintenance cost. It may be! But my suggestion was to prototype it,
and then canvas opinion as to whether to push it forwards. It's not just
"if I did this would you take the PR" — we need a consensus that yes, this
is a new group of checks we want to bring into the framework.
--
Ticket URL: <https://code.djangoproject.com/ticket/32523#comment:3>