#2367 closed enhancement (fixed)
[patch] pagination for date based generic views
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Generic views | Version: | dev |
Severity: | normal | Keywords: | |
Cc: | DaNmarner@…, paolo@…, yatiohi@…, joesaccount@…, aidan@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Date based views do not have pagination. This patch adds pagination to the archive_day, archive_week, archive_month generic views. archive_index does not require pagination because of the num_latest argument.
Attachments (6)
Change History (25)
Changed 17 years ago by
Attachment: | date_based_paginate.diff added |
---|
comment:1 follow-up: 3 Changed 17 years ago by
comment:2 Changed 17 years ago by
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:3 Changed 17 years ago by
Replying to mtredinnick:
If we commit this, I think we should add pagination to archive_index as well, since
num_latest
does not help you view "the second page of the latest headlines".
I agree. My original logic in that was flawed. Pagination should exist in all generic date based views.
comment:4 Changed 17 years ago by
Cc: | paolo@… added |
---|
My patch adds pagination capabilities to each date based generic view, except object_detail.
If it will be accepted for checkin I'll be glad to add a patch to update the documentation as well.
Changed 17 years ago by
Attachment: | date_based_pagination.diff added |
---|
pagination for each date_based
comment:5 Changed 17 years ago by
Patch needs improvement: | set |
---|
I like the factoring out of the common elements. Why not put everything in the Paginator object though, something along the idea of the patch attached to #1374? Also, whatever we do, it should be done for all the generic views, not just the date_based.
comment:6 Changed 17 years ago by
Next week I'll work on that.
What I can do is to move inside Paginator the function for queryset computation and context updating. Then I'll change list_detail generic views to use this code.
You say that it should be done for *all the generic views*, *not just the date_based*. But after the new patch, both date_based and list_detail will use the same code for pagination. Simple generic views and CRUD shouldn't have the needing of pagination, isn't it?
comment:7 Changed 17 years ago by
By all generic views, I meant all the ones where it makes sense, but I guess besides the date_based views, object_list is the only other one that makes sense.
comment:8 Changed 17 years ago by
Searching Django's related groups for more info about pagination I saw there have been a lot of discussions about "how Paginator should be" (to cite one, http://groups.google.com/group/django-users/browse_frm/thread/6963a1fdb6473352/d4622e25fc54bade). Even so, Paginator class hasn't changed in time (except for orphans handling), probably because features that actually provides are ok for the most of people. Thus I'd prefer not to change Paginator's code (that's working well btw).
In the light of what said, the latest patch (generic_views_pagination.diff) adds a new function at paginator module leaving Paginator class untouched. Then, it changes date_based and list_detail generic views to using this function to retrieve the paginated queryset and update the context with pagination variables.
Any chance anyone would comment and/or test the patch?
Thanks.
Changed 17 years ago by
Attachment: | generic_views_pagination.diff added |
---|
comment:9 Changed 17 years ago by
Don't consider the last patch I uploaded, it has at least two issues, introduces a dependency on django.http and uses allow_empty which is not defined there. Et voilà!
Changed 16 years ago by
Attachment: | 5992-pagination-for-datebased-generic-views.diff added |
---|
removed Http404 dependency in pagination.py, reraised InvalidPage, wrapped compute_pagination in a try except, use count instead of len on queryset.
comment:10 Changed 16 years ago by
Added a patch that fixes some of the issues mentioned.
Added a page argument to object_detail that is passed to context.
comment:11 Changed 16 years ago by
Triage Stage: | Design decision needed → Accepted |
---|
comment:12 Changed 16 years ago by
Cc: | yatiohi@… added |
---|
Changed 15 years ago by
Attachment: | django_pagination.diff added |
---|
The previous patch uses the deprecated ObjectPaginator class and changes paginator.py. This patch changes only date_based.py and uses the newer interface as defined in list_detail.py's object_list method.
comment:13 Changed 15 years ago by
Cc: | joesaccount@… added |
---|
comment:14 Changed 15 years ago by
Cc: | aidan@… added |
---|
comment:15 Changed 13 years ago by
Needs tests: | set |
---|
comment:16 Changed 13 years ago by
Another hard part of paginating based on date is what happens when an item is added to the list when you're paginating? If i go to the "previous" page there is a possibility that I will miss and item because it has been bumped off of the page. I dunno if there's a good way to fix this (peg the pagination to a certain pk in the URL? bleeh). But it's at least worth noting in the docs if this gets merged.
comment:17 Changed 13 years ago by
Cc: | DaNmarner@… added |
---|---|
milestone: | → 1.3 |
comment:18 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Function-based generic views were deprecated by the introduction of class-based views in [14254]. Class-based views should solve this problem.
If we commit this, I think we should add pagination to archive_index as well, since
num_latest
does not help you view "the second page of the latest headlines".