#32523: Warn when trying to use a widget as a field in a form
----------------------------------+--------------------------------------
Reporter: Anders Hovmöller | Owner: nobody
Type: New feature | Status: closed
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 <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.c3adaa1633471f40c315ef6fa696b68f%40djangoproject.com.
