Adding a template tag to generate query strings

Django Internals
41

Hello again!

We have landed the template tag rename and I have started work on:

  1. Some polishing of existing docs in ref. I think it’s not explicit in the initial description of the tag that you can pass foo=val as argument, a first read suggest that only a QueryDict or request.GET will be accepted.
  2. Reviewing PR #18368 which adds supports for passing a dict as parameter.

I was aiming at having both items ready for the 5.1RC release. However, @sarahboyce rightly pointed out that the second item may need to be treated as a 5.2 improvement, with its corresponding release note, as it’s not strictly a release blocker.

But, I think that a common use case for this template tag will be passing dictionaries to create a properly formatted and encoded query string. Currently, creating a QueryDict from a dictionary feels cumbersome, especially since I couldn’t find a straightforward method to do so. It seems the options are either using urlencode on the dictionary and then passing the resulting string to QueryDict, or initializing an empty QueryDict with mutable=True and updating it with the desired dictionary.

Because of the above, I propose that we do include PR #18368 changes in 5.1 as a (sort of?) release blocker to improve and streamline the usage of this template tag.

Thoughts?

42

In my (limited) experience the main usecase is passing request.GET and altering parameters there. The common example being having /users?page=3 and toggling &sort=username etc… If you need to change more than one field, having a form which submits properly covers the remaining cases (though I admit that I might miss something here, but those are my personal usecases so far).

As such I am fine with not having (2.) in 5.1 – but I have no string feelings.

43

Hello,

A simple example for using dicts along with forms is [<] and [>] buttons like these:

grafik
grafik1153×74 9.58 KB

The form is constructed from the view’s query parameters. The two buttons are “quick actions”, that is, links to the same view that must share the same parameters as the form but override the month and year with precomputed values for the previous and next time period:

{% querystring request.GET prev_period_month_and_year %}

So, personally I think it would be helpful to have this in 5.1. :stuck_out_tongue_winking_eye: