On 10/12/06, sago <[EMAIL PROTECTED]> wrote: > So I suggest, its time to see what people need from Paginator and make > a serious joint contribution to a complete system.
Thanks for bringing this up. I'd like to make some big improvements to the paginator class, and you touched on most (all?) things that I'd like to improve... > 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). I love the idea of a Paginator class that knows what page it's on. The patch in http://code.djangoproject.com/ticket/2576 does exactly this. I'd prefer to have it be a separate class, rather than make Paginators optionally page-aware. > 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). We already cover c) with paginator.hits. As for b), it'd be nice to have a paginator.firstindex and paginator.lastindex, or some better name. And a) is achieved by paginator.get_page(). > 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... Yes! I've implemented this so many times on my own that I think it should be in the paginator class. > 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. I've done the [1, 2, None, 12, 13...] thing myself. Let's do this in paginator as well. > 5. Orphans - see Chris' ticket. I'm not 100% sold on this, but I'll give it some more thought... > 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?] The problem with QuerySets implementing __len__ is that sometimes you care about the length of the QuerySet *after* the query has been done, and sometimes you care about the number of records (i.e., *before* the query has been done). I like this suggestion for the paginator, though. What about one of these solutions: * Try .count() first. If the method doesn't exist, use len(). * Pass an optional count_method to the constructor, which defaults to 'count', but people could pass in '__len__' if they wanted. This is slightly less elegant than the previous solution. * Or, both! > 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. I think this wouldn't be necessary if we had a PaginatorPage (as suggested in #2576), because, in theory, the PaginatorPage would have access to all the stuff you needed in your template. Am I missing something? > 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? The paginator class has never been documented in the official docs (with a small exception being in a model example), so we're not locked down on its API. And really, the types of things we're talking about here are enhancements, not necessarily backwards-incompatibilities. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
