I have a view in django that can accept a number of different filter parameters, but they are all optional. If I have 6 optional filters, do I really have to write urls for every combination of the 6 or is there a way to define what parts of the url are optional?
To give you an example with just 2 filters, I could have all of these url possibilities:
/<city>/<state>/
/<city>/<state>/radius/<miles>/
/<city>/<state>/company/<company-name>/
/<city>/<state>/radius/<miles>/company/<company-name>/
/<city>/<state>/company/<company-name>/radius/<miles>/
All of these url's are pointing to the same view and the only required params are city and state. With 6 filters, this becomes unmanageable.
What's the best way to go about doing what I want to achieve?
Try use something like that in your urls.py:
This is absolutely the use-case for GET parameters. Your urlconf should just be
/city/state/
, then the various filters go on the end as GET variables:Now, in your view, you accept
city
andstate
as normal parameters, but everything else is stored in therequest.GET
QueryDict.You could also make just one url (that only checks the start of the path, that should be the same) pointing to your view and then parse
request.path
in your view. On the other hand, if you have really many optional filter parameters in various combinations the best solution is very often to do th filtering viaGET
-parameters, especially if the urls used for filtering don't need to be optimized for any search engine...One method would be to make the regular expression read all the given filters as a single string, and then split them up into individual values in the view.
I came up with the following URL:
Matching the required city and state is easy. The
filters
part is a bit more complicated. The inner part -(?:/[^/]+/[^/]+)*
- matches filters given in the form/name/value
. However, the*
quantifier (like all Python regular expression quantifiers) only returns the last match found - so if the url was/radius/80/company/mycompany/
onlycompany/mycompany
would be stored. Instead, we tell it not to capture the individual values (the?:
at the start), and put it inside a capturing block which will store all filter values as a single string.The view logic is fairly straightforward. Note that the regular expression will only match pairs of filters - so
/company/mycompany/radius/
will not be matched. This means we can safely assume we have pairs of values. The view I tested this with is as follows:Two things to note about this. First, it allows unknown filter entries into your view. For example,
/fakefilter/somevalue
is valid. The view code above ignores these, but you probably want to report an error to the user. If so, alter the code getting the values toAny entries remaining in the
filters
dictionary are unknown values about which you can complain.Second, if the user repeats a filter, the last value will be used. For example,
/radius/80/radius/50
will set the radius to 50. If you want to detect this, you will need to scan the list of values before it is converted to a dictionary: