Short story:
We want to hear your voice to help us decide how @paginate should
handle "out of bound" pages.
======
Long story:
Given this method on your root controller:
@expose()
@paginate("data", limit=3)
def test(self):
data = [1, 2, 3, 4, 5, 6, 7, 8]
return dict(data=data)
Ideally the page number should be a natural number, from 1 to page_count (3)...
Lets call this method, varying "tg_paginate_no" parameter from 1 to 5:
(http://localhost:8080/test/?tg_paginate_no=1)
These are our results:
page 1 => result = [1, 2, 3]
page 2 => result = [4, 5, 6]
page 3 => result = [7, 8]
page 4 => result = []
page 5 => result = []
As you can see, pages 4 and 5 result in empty data... This is
something that can happen in real life, specially if you are browsing
volatile data.
Eg: you are browsing orders with "Waiting for approval" status, and
you unluckily clicked on a page that doesn't exists anymore, because
lots of records have their status changed (or were deleted).
So far so well...
Now, if we tamper our tg_paginate_no once again, but with 0 (zero) or
negative numbers, we get:
page -3 => result = []
page -2 => result = [1, 2]
page -1 => result = [3, 4, 5]
page 0 => result = []
As you can see, pages -3 and 0 make some sense, since we don't have
any data to display... but pages -2 and -1 are clearly giving strange
data, and this behavior must be corrected.
While talking with Florent about this situation, we got different
ideas on how paginate should handle this 2 "out of bound" scenarios.
So here goes the poll. You can answer the traditional "+1" text, but
don't forget to specify your options and/or make a comment:
=====================
[Scenario 1]: Page <= 0
a) Passive mode: return empty data ([])
b) User-friendly mode (adjust page to 1 automatically and return the
corresponding data)
c) Aggressive mode: raise a 404 error.
[Scenario 2]: Page > page_count
a) Passive mode: return empty data ([])
b) User-friendly mode (adjust page to 'page_count' automatically and
return the corresponding data)
c) Aggressive mode: raise a 404 error.
[Scenario 3 (bonus)]: Special case: page_count == 0
For this third scenario, I strongly believe we should try to return
empty data, unless...
... unless the page <> 1, which bring us to the same options:
a) Passive mode: return empty data ([]) and leave the page number as it is.
b) User-friendly mode (adjust page to '1' automatically and return the
empty data)
c) Aggressive mode: raise a 404 error.
=====================
Just as an information, Google choose the (b) option for its search page.
Eg: try doing this search (it was hard to find some search items that
would bring few pages):
http://www.google.com.br/search?q=roger+demetrescu+components+delphi&hl=pt-BR&start=10&sa=N
If you tamper the "start" parameter to -5 or 80, you will see google
showing the 1st or the 2nd page... no empty return... no 404 error...
(actually, if you tamper to a number >= 991, you may get empty data
... strange, isn't it ?)
Well, I hope I didn't forget any detail.
We really appreciate your feedback. The idea is to make the changes
before the 1.0.4 final release (with tests, of course).
Cheers,
Roger
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
