#29010: Allow customizing the autocomplete search results based on the querying
model
-------------------------------------+-------------------------------------
Reporter: Muslu Y. | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.0
Severity: Normal | Resolution:
Keywords: ForeignKey, | Triage Stage:
get_search_results, search_fields | Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by David W. Lloyd):
Replying to [comment:6 Johannes Hoppe]:
> To add a bit more context here, we did have an intermediate solution
that would have made this easier. A view per widget. We ultimately dropped
that approach to decrease complexity. A decision I still support.
Was there no in-between option? This severely limits the usefulness of the
widget... as a separate-but-related issue:
- the new autocomplete widget ignores any filtering done in the
"limit_choices_to" ORM definition, unlike a regular select field; not very
DRY, since limit_choices_to can, with other widgets, be used to filter
lookups effectively... inconsistent, unintuitive behavior. If you're not
going to fix it, perhaps update the autocomplete documentation to mention
that limit_choices_to is completely ignored...
- the new autocomplete widget ties its ordering of results to the
ModelAdmin in question, which is also unintuitive if your ModelAdmin has a
default ordering other than alphabetical... for example, if you want the
ModelAdmin to default to showing the newest entries, your autocomplete
results will ALSO be ordered thus, but such sorting is extremely confusing
and unlikely to be helpful in a type-ahead scenario
Your proposal to use django-select2 or DAL almost makes me wonder: why add
autocomplete to the admin at all, then? It's 2018, this is a standard
design pattern for administrative backends, and to omit the ability to
filter based on referring entity, to ignore limit_choices_to, and to
tightly couple autocomplete result sorting to default ModelAdmin result
sorting seems highly counterintuitive in a pretty common set of use cases.
> My suggestion would be use an external library like `django-select2` or
`django-autocomplete` if you want to implement more sophisticated logic.
> Please also keep in mind, the admin is not recommend to be used for
sofistikated user interfaces.
Based on the packages out there targeting the admin & the extensive
articles on customizing it, that recommendation just seems optimistic.
Django's built-in admin is hailed as one of its selling points, and the
fact that it HAS a strong built-in solution has probably discouraged the
creation of third-party standalone packages targeting scaffolding &
building admin backends - why reinvent the wheel? This recommendation
seems to ignore reality - many folks are using the admin to build complex
interfaces, the autocomplete in 2.0 *can* really help us all out, but it's
a little half-baked at the moment. Baking it some more, to allow for
filtering based on relation and decoupled sorting, seems like a high-value
enhancement...
--
Ticket URL: <https://code.djangoproject.com/ticket/29010#comment:7>
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.baa73404326d05671909ee5c026aea40%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
