[Django] #26260: Support of object_list in ModelChoiceField and ModelMultipleChoiceField
Django
-----------------------------+--------------------
Reporter: srkunze | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------
We encountered the need of having object_list (list of model instances)
instead of a queryset several times when initializing a ModelChoiceField
or ModelMultipleChoiceField.
Is there some chance of getting this implemented?
--
Ticket URL: <https://code.djangoproject.com/ticket/26260>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: srkunze | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
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 timgraham):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I seem to remember this being discussed before but am not finding anything
right away. Is there a problem converting a list of instances to a
queryset using something like `queryset=Model.objects.filter(pk__in=[x.pk
for x in object_list])`?
--
Ticket URL: <https://code.djangoproject.com/ticket/26260#comment:1>
Django
Reporter: srkunze | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I'm probably remembering #23672 (marked as wontfix) which proposes similar
functionality for `BaseModelFormset`.
--
Ticket URL: <https://code.djangoproject.com/ticket/26260#comment:2>
Django
Reporter: srkunze | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by TZanke):
* cc: tzanke@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/26260#comment:3>
Django
Reporter: srkunze | Owner: nobody
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => needsinfo
--
Ticket URL: <https://code.djangoproject.com/ticket/26260#comment:4>
Django
Reporter: srkunze | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by srkunze):
* status: closed => new
* resolution: needsinfo =>
Comment:
Sure, recreating a queryset from the object list is also our current
approach.
We could identify two issues so far:
1) code duplication (already observed)
2) performance
Number 2) worries me most as we observed performance issues recently. So,
this only contributes further.
Perhaps it would help when I explain our use-case.
We designed tree widgets for both choice and multiple choice fields. They
work quite well when all items can be expressed easily on terms a regular
queryset. However, as you can imagine, tree data enables some pretty
interesting and complex use-cases. So, the object list is built
differently here.
Currently, we cheat by using the ModelChoiceIterator as it exposes the
original queryset to the widget.
--
Ticket URL: <https://code.djangoproject.com/ticket/26260#comment:5>
Django
Reporter: srkunze | Owner: nobody
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => wontfix
Comment:
Have you considered a custom field instead? Looking at the code of the
fields you mentioned, it doesn't look to me like a dual purpose
implementation that allows either a queryset or a list of instances would
be simple. As to whether or not such a field should be included in Django
itself, I'd suggest to write to the DevelopersMailingList to get feedback
on it if you have some code to show. Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/26260#comment:6>