All, I filed a bug in paginator last week. SmileyChris pointed out that his extra-features patch would solve the bug, and add orphan control (so you don't get one post on its own page at the end).
I've got a pimped-up version of paginator too, and judging from searches, it seems like lots of folk have. So I suggest, its time to see what people need from Paginator and make a serious joint contribution to a complete system. My twopenneth: 1. Is there any point in having a paginator object and then having to request data from it on a page by page basis? IMHO the use-case is: create a query set, feed it to a paginator, tell the paginator which page of results you want, render that page. So the paginator should have a set_page method (related to 7 below). 2. Most page-by-page views have this data: a) The list of objects on that page. b) The 1-indexed number of the first and last object on the page (e.g. results 1-10). c) The total number of results (e.g. results 1-10 of 100). 3. I can think of many applications where it is useful to be able to move between pages. Has next and Has previous is fine. But forums, google &c often have a page list. It would be useful to have paginator returning a list of pages (e.g. if pages returns 4, it would be nice to have something returne range(1,5)). It isn't hard to trap the number of pages and run it through range, of course, but DRY suggests this could be in the paginator class rather than any view that needs it. This becomes more critical with... 4. More intelligent lists of pages. In my application there may be many tens of pages. So I do a google-like thing of having a subset of the pages as direct links. If the user is on page 15 of 50, for example, I might have links to pages [1,2,12,13,14,15,16,17,18,49,50]. Actually I like to have dots to signify non-contiguous numbering. So currently I return [1,2,None,12,13... etc], but that may just be me. 5. Orphans - see Chris' ticket. 6. Fallback to finding the number of hits with len() rather than .count(). That single change would allow paginators to paginate any sequence-like object, not just query sets. [As an aside Django's query sets should probably implement __len__ as an alias for .count() to be more 'pythonic'. Would this cause any side-effects?] 7. You should be able to get a whole dictionary of data about the page back in one go. So I can just get my page information (consisting of the above) and pass it right along to the template renderer. This again is a DRY principle related to the most common use-case of getting paginator to group objects onto a page and return the data needed to render it. Having to pull individual bits of data out of paginator and add them to a dictionary or to the context is very timeconsuming. It should be a separate dictionary rather than writing to the context so that multiple paginated lists can sit on one page easily. Any other comments, suggestions? And to any of the Django admins - would a substantial upgrade of this kind to paginator be allowable, or are you locked down on its API until v2? Ian. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
