#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 Johannes Hoppe):
Replying to [comment:7 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:
I agree, but this feature took ten years to be implemented. We decreased
scope to decrease complexity. Now that it's out we can see what additional
features get requested and chose to work on those.
> - 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...
I agree this is a problem. I would much welcome a fix here to. It seems we
all missed in the reviews.
> - 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
The sorting is only there for pagination purposes but it can be used to
improve results. I use the widgets on full text indexes too, which go way
beyond a simple typeahead.
> 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.
Go ahead an decouple it. That's an easy one. You add a new method that by
defaults calls the current soring method. Please open a separate issue for
that one. I would be happy to review this feature.
> > 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...
Please not that these 3rd party librarie have been around a lot longer
than the new admin feature – no wheel reinvention happening. Furthermore
they address a lot more use cases they are meant for user interaction
(none-admins).
It's a pretty big hypophysis that "many folks are using the admin to build
complex interfaces", even though this is discouraged. In general I would
kindly ask you to watch your tone. This feature is a result of a lot of
hard work by "many folks". Phrases like "half-baked" may hurt people's
feelings.
You have to chose here, you either: Love it, change it or leave it.
--
Ticket URL: <https://code.djangoproject.com/ticket/29010#comment:8>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.4750f1995514a8c4bd34e3106c41c12f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
