Malcom, Yes, I agree that it is better to have a generally useful framework, rather than an all singing and dancing solution to everybody's solution but yours. I also agree with a lot of your post.
> Pagination is something that can and is presented in many > different ways. This is a subtext of my post really. I wanted to garner people's use/expectation from the system. Mainly because my use/expectation was so clearly different from the facilities that it provided, and it seemed to me that I wouldn't be alone. If there are three common ways that people always use paginator, and 90% of people use one, and the other two are exotic, then it makes sense (at least to me) to add a class that supports those 90%. > Some pages do operate in this way, it's true. Making it possible to work > like this is a good goal. Encouraging people to work this way is less of > a goal, since it's only one way to operate. So, I guess the question is what are the other ways ? > > 3. > > 4. > There's just no end to the bells and whistles > department and once you walk in there, it's hard to leave. On reflection, you're probably right. > There's no > "DRY" violation, because you end up writing your utility method exactly > once (it only becomes 'R' on the second and subsequent times). The Y in DRY can be plural 'you', not just singular. If both you, and I and a thousand other programmers are all writing functionally the same bit of code, that is wasteful. In the admin interface for example, Django sensibly assumes that 90% of people will want roughly the same thing, and provides the support for the other 10% (actually, strictly, LJW happened to have requirements from its admin interface that 90% of the rest of us happen to share). As long as you continue to support the other 10% its a noble aim, IMHO, to provide for the needs of the 90%. > > [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?] Anyone want to comment on this? > > 7. You should be able to get a whole dictionary of data about the page > > back in one go. > This kind of assumes there is a universal concept of "the right data". I > would dispute that. There is already a concept of "the right data" because the class supports querying of some data but not others (as you've said, some bits of data you need to calculate yourself, the paginator shouldn't provide them). Since the queries that are involved in calculating the paginators internal data are effectively redundant (hence the assignment to ._hits etc. in the class). Having a method to get all the data and return it in a dictionary would be very useful and non-controversial, surely. And it would solve the 'set_page' problem too. Just call get_page_data(page_number) and get all the information in a dictionary, or object. > Your "most common" use-case isn't necessarily somebody elses. Locking > people in at the framework level is not nice. I agree with the second sentence. But not the first - what more common use-case for paginator is there than grouping objects on a page? Surely the name gives it away. > You forgot to mention the elephant in the room, though: people are going > to want to use this functionality through generic views. Yes, but its a small elephant, a baby Indian, I guess. > custom paginator object, then you can't use generic views. They are an > aid, not a crutch, after all. I expect that to fly like a lead balloon. I think you're right. Generic views are all about assuming things. For example, I rarely use Generic views because most of the work I do needs other information on the page, so even if you're looking at one db object, I need other objects rendered in some way. So it seems fine to me to assume that people who use generic views get generic parameters in a generic paginator. Anyone else can write a custom view. Thanks for the response Malcom, 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 -~----------~----~----~----~------~----~------~--~---
