Add querystring helper methods to Page class

[Ben Spaulding]

A ticket has already been created for this, but SmileyChris
recommended I bring the issue up here.

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 functionality belong
in Django’s pagination.

Ticket: http://code.djangoproject.com/ticket/10941
Patch: http://code.djangoproject.com/attachment/ticket/10941/querystring-methods.diff

[Hanne Moa]

2009/12/22 Ben Spaulding <ben.sp...@gmail.com>:

> I have created a patch that would allow for something much simpler, like so:
>
> <a href="?{{ page.next_page_querystring }}">Next page</a>

This is what I do in my own homemade paginators. It works well.

> 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),

Actual full pagination-bars could be shipped around as templates,
whether to be used in inclusion-tags or included directly. No need to
lock ourselves to the one, true pagination-style.

HM

[veena]

Hi,
I need similar functionality so I develop custom tag "qs" wich is not
tight to paginator (I don't know if it is better or not)

Used that way:
<a href="{% url list %}{% qs params p=pager.previous_page_number %}">

params ... dictionary with query string parameters which was prepared
in view
p ... any amount of other query string parameters as key=value you
want to set directly in template

For filtering query string parameters in views for using them as
parameters in ORM, redirects etc I use function "dict_pass()" with
this pattern:

search_params = ('a_day', 'a_month', 'd_day', 'd_month',
'guest_count', 'bedrooms', 'p', 'o', 'ot', 'short') #allowed params
params = dict_pass(request.GET, search_params, updated_params)

It returns dictionary of parameters of "request.GET" updated from
"updated_params" and filtered to have only allowed params here as
"search_params".

I think Django as a web framework could have an object oriented
representation of URI in core to simplify the work with url. It should
be easy to set, update and get the whole url as a string and also url
parts (host, port, path, etc.) and query string parameters in some
clever way without bunch of conditions in application code needed. And
also maybe help with proper escaping of urls with not ascii chars to
render them in templates.

Some inspiration from other web frameworks:
http://api.nettephp.com/0.9/Nette-Web/Uri.html
http://corelib.rubyonrails.org/classes/URI/Generic.html
http://framework.zend.com/manual/en/zend.uri.html

I think also get_absolute_url proposal and future url routing
enhancements could benefit from it.

Cheers,
Vaclav