#5833: Custom FilterSpecs
-------------------------------------+-------------------------------------
Reporter: | Owner: jkocherhans
Honza_Kral | Status: assigned
Type: New | Component: contrib.admin
feature | Severity: Normal
Milestone: | Keywords: nfa-someday
Version: SVN | list_filter filterspec nfa-
Resolution: | changelist ep2008
Triage Stage: Accepted | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 |
-------------------------------------+-------------------------------------
Comment (by kmtracey):
I experimented with this a bit today, and was able to use the doc to
implement my particular need without too much difficulty so that is good.
One thing I thought was odd though was that my filter's `get_query_set` is
called even if its `query_parameter_name` is not in request.GET, and as a
result my `get_query_set` must be coded to handle that case properly
(return the queryset unchanged). If it is not coded properly the result is
that my filter limits the queryset used even when its "All" choice is the
selected choice for it. I think it would be preferable to avoid calling
the `get_query_set` for filters whose query parameters aren't in
`request.GET`.
There is no mention anywhere I could see of why `request` is passed into
`get_choices` and `get_queryset`, nor is it used that I can see anywhere
in the samples. For what kinds of filters might this be used?
My particular use case is a slight modification of an existing admin
filter: I want to filter by a related field, but I only want a subset of
the existing values to appear in the choices. It was not hard to implement
as a !ListFilter but after getting `get_query_set` wrong the first time it
occurred to me it would be better if I could just override the
`get_choices` method for the existing admin filter that already filtered
the way I wanted. Unfortunately that existing admin filter isn't
implemented as a !ListFilter so I can't do that, apparently I'd have to
choose the scary-sounding alternate option of providing a tuple of field
name and class inheriting from !FieldListFilter (which is noted as being
internal and prone to refactoring). Is it not possible to unify things so
that it is easy to both write completely new-and-different filters and
ones that are minor tweaks to what admin already provides?
--
Ticket URL: <http://code.djangoproject.com/ticket/5833#comment:118>
Django <http://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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
