Opened 6 years ago

Last modified 2 years ago

#10941 new New feature

Add querystring helper methods to Page class

Reported by: benspaulding Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords: pagination
Cc: dan.fairs@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Working with pagination and query strings within a template can be painful. Personally, I have never had a situation when I was paginating using a GET parameter where there were not other parameters that needed to be preserved through out the various pages.

Take search, for example. There may be parameters for searching within one or more models, for a particular author and sorting by date. Maintaining all of these parameters within the pagination links takes some serious template logic.

{# Linebreaks added for readability. In real life this would need to be one, long line. #}
<a href="?{% for key, values in request.GET.iterlists %}
  {% ifnotequal key "page" %}
    {% for value in values %}
      {{ key }}={{ value }}&amp;
    {% endfor %}
  {% endifnotequal %}
{% endfor %}page={{ page.next_page_number }}">Next page</a>

That kind of logic shouldn’t be in a template. I have created a patch that would allow for something much simpler, like so:

<a href="?{{ page.next_page_querystring }}">Next page</a>

Though there has been much talk of creating template tags which would produce all-out pagination bars, I believe this particular functionality should be an actual method on the page object for two reasons:

  1. This is basic functionality whose end result is hard to dispute (as opposed to a full pagination bar where markup and features could be disputed eternally),
  2. This does not require the request context processor to be installed.

Note that this patch includes documentation. Tests are still needed. I am not married to the exact implementation, but I and others I have discussed this and feel that this simplicity and fuctionality belong in Django’s pagination.

Attachments (1)

querystring-methods.diff (3.8 KB) - added by benspaulding 6 years ago.
Methods for handling pagination query strings, documentation.

Download all attachments as: .zip

Change History (11)

Changed 6 years ago by benspaulding

Methods for handling pagination query strings, documentation.

comment:1 Changed 6 years ago by gregplaysguitar

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I'm in favour of this proposal

comment:2 Changed 6 years ago by daybreaker

comment:3 follow-up: Changed 5 years ago by SmileyChris

  • Needs tests set
  • Triage Stage changed from Unreviewed to Design decision needed

Patch seems like a good idea - should be brought up in the django-dev google group.

comment:4 in reply to: ↑ 3 Changed 5 years ago by benspaulding

Replying to SmileyChris:

Patch seems like a good idea - should be brought up in the django-dev google group.

Thanks for the advice. I have started a discussion on django-dev: Add querystring helper methods to Page class.

comment:5 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:6 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:7 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:8 Changed 3 years ago by danfairs

  • Cc dan.fairs@… added

comment:9 follow-up: Changed 2 years ago by apollo13

  • Triage Stage changed from Design decision needed to Accepted

Oh yeah, I run into this all the time. I think that we should allow customization of the querystring name, eg 'p' instead of 'page'. To that end a simple filter and/or tag might be better.

comment:10 in reply to: ↑ 9 Changed 2 years ago by benspaulding

Replying to apollo13:

Oh yeah, I run into this all the time. I think that we should allow customization of the querystring name, eg 'p' instead of 'page'. To that end a simple filter and/or tag might be better.

Just to be clear, drop the helper methods and go with a filter or tag, requiring use of the django.core.context_processors.request? (Sounds fine to me, I just want to be clear on the recommended route so this doesn’t bog down in implementation.) What template tag library would that live in? There doesn’t seem to be a current contrib app it would fit in, and I am not sure it belongs in built-ins if it depends on a context processor that is not installed by default.

Note: See TracTickets for help on using tickets.
Back to Top