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):
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).
> We want to hear your voice to help us decide how @paginate should > handle "out of bound" pages.
> ======
... > Long story:
> 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 = []
shouldn't it gives page -1 => [7, 8] (the last page) page -2 => [4, 5, 6] etc. ?
in many systems -1 means the last item/page/what ever. and does not have the same meaning as "display a full page starting from the last item" which would be page 1 with a reverse sorting order the the list to be displayed.
> =====================
> [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.
> 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.
b) > [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.
> a) Passive mode: return empty data ([]) > b) User-friendly mode (adjust page to 1 automatically and return the > corresponding data)
+1 on b
> 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)
I'm undecided. Certainly _not_ c though, with a slight preference on a - but then, I'm a developer, so I know that non-existing pages are empty. So - I'm totally ok with b as well.
> 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.
Simply returning empty data is enough here I'd say.
Em Wednesday 31 October 2007 23:26:16 Roger Demetrescu escreveu:
> =====================
> [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.
+1 on B and on having the page number fixed on the URL / HTML code automatically to reflect that.
> [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.
+1 on B and on having the page number fixed on the URL / HTML code automatically to reflect that.
> [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.
+1 on B and on having the page number fixed on the URL / HTML code automatically to reflect that.
> le 01.11.2007 02:26 Roger Demetrescu a écrit: > > 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 = []
> shouldn't it gives > page -1 => [7, 8] (the last page) > page -2 => [4, 5, 6] > etc. ?
> in many systems -1 means the last item/page/what ever. > and does not have the same meaning as "display a full page starting from > the last item" which would be > page 1 with a reverse sorting order the the list to be displayed.
Do you mean we should accept -1 as how it is and display the last page ? Or do you mean we should replace -1 with the "page_count" and then show the corresponding page ?
Notice that these 2 options will bring the same result... but the 1st option will cause problems to PaginateDataGrid (or other custom widgets / paginate navigators). They will render links as:
-2, -1, 0, 1
And I doubt this is something natural to user...
IMVHO, it only leads users to confusion... not everyone has this understanding....
The idea of handling negative pages is just to avoid invalid pages if someone tampers the URL parameter. PaginateDataGrid will never render such a negative page number link... (or if a programmer write his own page navigator with bugs).
If you have the intention of give the user a "last" page, you have this available in cherrypy.request.paginate.page_count... If you want to be sure this "page_count" will be really the last page after 10 minutes, you can always multiply it by 1000... ;) (of course, assuming we will use the Friendly User Mode)
On Nov 1, 2007 7:15 PM, Jorge Godoy <jgo...@gmail.com> wrote:
> Em Thursday 01 November 2007 19:13:24 Roger Demetrescu escreveu:
> > Do you mean we should accept -1 as how it is and display the last page ?
> I believe he was saying that we should handle "-1" as Python does for lists. > I.e, -1 is the last element, -2 is the penultimate, and so on.
Ok... let me clarify...
Suppose we have to paginate some data which has 20 pages.. If @paginate receives a request to show data with page -2, we would show the 19th page. Ok here...
My question is: what would be the value from tg.paginate.current_page ? -2 or 19 ?
If the paginate is configured with max_pages=3, and the tg.paginate.current_page == 19, then tg.paginate.pages would be [18, 19, 20]
But, if tg.paginate.current_page is going to maintain the -2 value, what do you expect from tg.paginate.pages ?
[-1, -2, -3] ?
Does it make sense in a grid's navigation header ?
Make current_page -1 behave as list[-1] from python isn't difficult... But showing some consistent pages links may be a challenge...
On Nov 1, 2007 7:00 AM, Jorge Godoy <jgo...@gmail.com> wrote:
> Em Wednesday 31 October 2007 23:26:16 Roger Demetrescu escreveu: > > =====================
> > [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.
> +1 on B and on having the page number fixed on the URL / HTML code > automatically to reflect that.
The page number fixed in HTML wouldn't be a problem, if we update tg.paginate.current_page with the corresponding positive number. The following HTML rendering would take advantage from this....
Regarding the fix in URL, do you mean the URL from the browser ? That would require us to force a redirect. This isn't a problem if we want to correct page -7 to page 1, because we can detect it before manipulating the data.
However, if we must correct page 700 to page 15, it will be after we have an idea of the data size... which mean we will hit the database if we are paginating SelectResults or Query. If we redirect the browser to a nice URL with page number fixed to 15, that will force us to hit the database again... Does it worth the effort ?
Using Google as an example again... if we tamper the "star" parameter from its URL to a value out of bound, it will adjust the data displayed to the 1st or last page...but the tampered parameter will remain in the URL... until you click on one of the pagination links..
> On Nov 1, 2007 7:15 PM, Jorge Godoy <jgo...@gmail.com> wrote:
>> Em Thursday 01 November 2007 19:13:24 Roger Demetrescu escreveu:
>>> Do you mean we should accept -1 as how it is and display the last page ?
>> I believe he was saying that we should handle "-1" as Python does for lists. >> I.e, -1 is the last element, -2 is the penultimate, and so on.
> Ok... let me clarify...
> Suppose we have to paginate some data which has 20 pages.. If > @paginate receives a request to show data with page -2, we would show > the 19th page. Ok here...
yes > My question is: what would be the value from tg.paginate.current_page > ? -2 or 19 ?
19 > If the paginate is configured with max_pages=3, and the > tg.paginate.current_page == 19, then tg.paginate.pages would be [18, > 19, 20]
> But, if tg.paginate.current_page is going to maintain the -2 value, > what do you expect from tg.paginate.pages ?
> [-1, -2, -3] ?
[18, 19, 20] > Does it make sense in a grid's navigation header ?
> Make current_page -1 behave as list[-1] from python isn't difficult... > But showing some consistent pages links may be a challenge...
> 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.
+1 on (b)
> [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.
+1 on (b)
> [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.
> le 01.11.2007 02:26 Roger Demetrescu a écrit: > > Short story:
> > We want to hear your voice to help us decide how @paginate should > > handle "out of bound" pages.
> > ======
> ...
> > Long story:
> > 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 = []
> shouldn't it gives > page -1 => [7, 8] (the last page) > page -2 => [4, 5, 6] > etc. ?
No. Roger is right to propose a sanitizing of user-input, especially for the cases where the results may change dynamically _while_ paging.
Using the negative page offset semantics above is neither intuitive (the pages are numbered, it's not that pagination shows a _range_, so what we are talking about is
pages[-2]
which is _one_ page, not the last 3 ones. Why should negative pagination values suddenly change the total number of results shown?
And don't forget that the negative numbering is a (very) convenient feature of python's list-indices, but _not_ something people in general have any expectations about.
> On Nov 1, 2007 7:00 AM, Jorge Godoy <jgo...@gmail.com> wrote: > > Em Wednesday 31 October 2007 23:26:16 Roger Demetrescu escreveu: > > > =====================
> > > [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.
> > +1 on B and on having the page number fixed on the URL / HTML code > > automatically to reflect that.
> The page number fixed in HTML wouldn't be a problem, if we update > tg.paginate.current_page with the corresponding positive number. The > following HTML rendering would take advantage from this....
> Regarding the fix in URL, do you mean the URL from the browser ? That > would require us to force a redirect. > This isn't a problem if we want to correct page -7 to page 1, because > we can detect it before manipulating the data.
> However, if we must correct page 700 to page 15, it will be after we > have an idea of the data size... which mean we will hit the database > if we are paginating SelectResults or Query. If we redirect the > browser to a nice URL with page number fixed to 15, that will force us > to hit the database again... > Does it worth the effort ?
> Using Google as an example again... if we tamper the "star" parameter > from its URL to a value out of bound, it will adjust the data > displayed to the 1st or last page...but the tampered parameter will > remain in the URL... until you click on one of the pagination links..
I'm also against that - "fixing" the url would mean a redirect. And especially when we get negative, it's the user who has tampered with the url - so whom are we try to kid? And that redirect might cause additional harm.
This proposal is about sanitizing user input, which is very valuable. But it shouldn't be blown out of proportion to apply general python list index semantics to url parameters, nor applying cosmetics.
> On Thursday 01 November 2007 10:28:19 remi jolin wrote:
>> le 01.11.2007 02:26 Roger Demetrescu a écrit:
>>> Short story:
>>> We want to hear your voice to help us decide how @paginate should >>> handle "out of bound" pages.
>>> ======
>> ...
>>> Long story:
>>> 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 = []
>> shouldn't it gives >> page -1 => [7, 8] (the last page) >> page -2 => [4, 5, 6] >> etc. ?
> No. Roger is right to propose a sanitizing of user-input, especially for the > cases where the results may change dynamically _while_ paging.
> Using the negative page offset semantics above is neither intuitive (the pages > are numbered, it's not that pagination shows a _range_, so what we are > talking about is
> pages[-2]
> which is _one_ page, not the last 3 ones. Why should negative pagination > values suddenly change the total number of results shown?
pages[-2] should produce the penultinate page, nothing less, nothing more (and pages[-1] the last page). I don't understand why pages[-1] should produce a page with items 3, 4, 5 as stated by Roger.
> And don't forget that the negative numbering is a (very) convenient feature of > python's list-indices, but _not_ something people in general have any > expectations about.
> pages[-2] should produce the penultinate page, nothing less, nothing > more (and pages[-1] the last page). > I don't understand why pages[-1] should produce a page with items 3, 4, > 5 as stated by Roger.
Ah, that was a misattribution then, sorry for that.
I still don't think that it should go in there. The reason is simple: even if we assume someone grasps it (which I suspect only programmers would), it's essentially a feature, disguised. Because there would be no way _except_ url tampering to get it.
> le 02.11.2007 10:44 Diez B. Roggisch a écrit: > > On Thursday 01 November 2007 10:28:19 remi jolin wrote:
> >> le 01.11.2007 02:26 Roger Demetrescu a écrit:
> >>> 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 = []
> >> shouldn't it gives > >> page -1 => [7, 8] (the last page) > >> page -2 => [4, 5, 6] > >> etc. ?
> > No. Roger is right to propose a sanitizing of user-input, especially for the > > cases where the results may change dynamically _while_ paging.
> > Using the negative page offset semantics above is neither intuitive (the pages > > are numbered, it's not that pagination shows a _range_, so what we are > > talking about is
> > pages[-2]
> > which is _one_ page, not the last 3 ones. Why should negative pagination > > values suddenly change the total number of results shown?
> pages[-2] should produce the penultinate page, nothing less, nothing > more (and pages[-1] the last page). > I don't understand why pages[-1] should produce a page with items 3, 4, > 5 as stated by Roger.
Hi Remi...
No, you misunderstood me.. :)
I am not saying page -1 __should__ produce result [3, 4, 5]. What I said in my original message is that __this is what happening now__ . You can try it yourself with the current paginate code.
If the result were:
page -3 => result = [1, 2, 3] page -2 => result = [4, 5, 6] page -1 => result = [7, 8] page 0 => result = []
... I would understand that it is behaving like a python list... But its not happening now... Below I am quoting my original message where I present the result paginate is giving now, when the whole data is [1, 2, 3, 4, 5, 6, 7, 8]
> >>> page -3 => result = [] > >>> page -2 => result = [1, 2] > >>> page -1 => result = [3, 4, 5] > >>> page 0 => result = []
It's very clear to me that this is a bug... Even if the intention of handling negative number was to present some data, where is the "6", "7" and "8" records ?
I think we all agree that raising a 404 error is a bad idea, so its a option we can discard. What we don't agree (yet ;) ) is what to do with this negative numbers:
(x) - Bring the last page when -1 is solicited. (y) - Bring the 1st page.
I'd also like to see any real examples of (x) method been applied. (like my Google example, which assumes the (y) method).
> On Nov 2, 2007 8:15 AM, remi jolin <remi.jo...@sysgroup.fr> wrote:
>> le 02.11.2007 10:44 Diez B. Roggisch a écrit:
>>> On Thursday 01 November 2007 10:28:19 remi jolin wrote:
>>>> le 01.11.2007 02:26 Roger Demetrescu a écrit:
>>>>> 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 = []
>>>> shouldn't it gives >>>> page -1 => [7, 8] (the last page) >>>> page -2 => [4, 5, 6] >>>> etc. ?
>>> No. Roger is right to propose a sanitizing of user-input, especially for the >>> cases where the results may change dynamically _while_ paging.
>>> Using the negative page offset semantics above is neither intuitive (the pages >>> are numbered, it's not that pagination shows a _range_, so what we are >>> talking about is
>>> pages[-2]
>>> which is _one_ page, not the last 3 ones. Why should negative pagination >>> values suddenly change the total number of results shown?
>> pages[-2] should produce the penultinate page, nothing less, nothing >> more (and pages[-1] the last page). >> I don't understand why pages[-1] should produce a page with items 3, 4, >> 5 as stated by Roger.
> Hi Remi...
> No, you misunderstood me.. :)
> I am not saying page -1 __should__ produce result [3, 4, 5]. > What I said in my original message is that __this is what happening > now__ . You can try it yourself with the current paginate code.
> If the result were:
> page -3 => result = [1, 2, 3] > page -2 => result = [4, 5, 6] > page -1 => result = [7, 8] > page 0 => result = []
> ... I would understand that it is behaving like a python list... But > its not happening now... Below I am quoting my original message where > I present the result paginate is giving now, when the whole data is > [1, 2, 3, 4, 5, 6, 7, 8]
>>>>> page -3 => result = [] >>>>> page -2 => result = [1, 2] >>>>> page -1 => result = [3, 4, 5] >>>>> page 0 => result = []
> It's very clear to me that this is a bug... Even if the intention of > handling negative number was to present some data, where is the "6", > "7" and "8" records ?
> I think we all agree that raising a 404 error is a bad idea, so its a > option we can discard. > What we don't agree (yet ;) ) is what to do with this negative numbers:
> (x) - Bring the last page when -1 is solicited. > (y) - Bring the 1st page.
I'd rather prefer to get (x), this would give a documented way to build a URL that will always bring the last page whatever the number of data is.
>> pages[-2] should produce the penultinate page, nothing less, nothing >> more (and pages[-1] the last page). >> I don't understand why pages[-1] should produce a page with items 3, 4, >> 5 as stated by Roger.
> Ah, that was a misattribution then, sorry for that.
> I still don't think that it should go in there. The reason is simple: even if > we assume someone grasps it (which I suspect only programmers would), it's > essentially a feature, disguised. Because there would be no way _except_ url > tampering to get it.
Well, I can think of applications where having a button to go to the last page of datas would be interesting. I agree that values <= -2 would not be very usefull.
> > (x) - Bring the last page when -1 is solicited. > > (y) - Bring the 1st page.
> I'd rather prefer to get (x), this would give a documented way to build > a URL that will always bring the last page whatever the number of data is.
Documented to whom? The user of the website? Certainly not.
And the programmer - well, the whole pagination machinery generates links, not the programmer. So _if_ there should be a way to get a "last page link", it should just be produced by the page-decorator somehow and e.g. put under a documented name into the request scope or something, so that one could render the link - as whole.
>>> (x) - Bring the last page when -1 is solicited. >>> (y) - Bring the 1st page.
>> I'd rather prefer to get (x), this would give a documented way to build >> a URL that will always bring the last page whatever the number of data is.
> Documented to whom? The user of the website? Certainly not.
I agree. > And the programmer - well, the whole pagination machinery generates links, not > the programmer. So _if_ there should be a way to get a "last page link", it > should just be produced by the page-decorator somehow and e.g. put under a > documented name into the request scope or something, so that one could render > the link - as whole.
Yes, of course, it would be simpler and much more elegant.
Em Thursday 01 November 2007 22:46:30 Roger Demetrescu escreveu:
> Regarding the fix in URL, do you mean the URL from the browser ? That > would require us to force a redirect. > This isn't a problem if we want to correct page -7 to page 1, because > we can detect it before manipulating the data.
The question that should be asked is: Why is there a negative number there? If it was a hand crafted URL, then a redirect is the best answer.
It it was programmatically inserted, then a redirect might be costly, but I still believe it is the best answer.
I don't see a reason to have negative numbers while using paginate.
> However, if we must correct page 700 to page 15, it will be after we > have an idea of the data size... which mean we will hit the database > if we are paginating SelectResults or Query. If we redirect the > browser to a nice URL with page number fixed to 15, that will force us > to hit the database again... > Does it worth the effort ?
I believe it does. It should never happen at first case (Why is the big number there when the dataset isn't so big? Hand crafted URL?).
> Using Google as an example again... if we tamper the "star" parameter > from its URL to a value out of bound, it will adjust the data > displayed to the 1st or last page...but the tampered parameter will > remain in the URL... until you click on one of the pagination links..
The problem here is that if a user cuts & paste the URL somewhere or to someone else, then there will be the fix overhead everytime the URL is accessed. What is more costly: fixing it once or fixing it dozens / hundreds / thousands (think search engines...) of times?
For a hand crafted and wrong URL, I don't see a problem on making the user wait. He should use navigational controls inside the application. If the users need something else with more frequency then the programmer has to take care of it. It is bad design to have users editing URLs to change behaviour on the application.
Em Friday 02 November 2007 07:47:13 Diez B. Roggisch escreveu:
> I'm also against that - "fixing" the url would mean a redirect. And > especially when we get negative, it's the user who has tampered with the > url - so whom are we try to kid? And that redirect might cause additional > harm.
What harm other than performing the query again? If it is a long running query, then one could introduce other mechanisms to block invalid ranges.
> This proposal is about sanitizing user input, which is very valuable. But > it shouldn't be blown out of proportion to apply general python list index > semantics to url parameters, nor applying cosmetics.
I don't think it is a cosmetic change if it will impact on search engine indexed links, for example, and if it will introduce extra burden every time a URL that was copied somewhere was wrong.
On Nov 3, 2007 10:10 AM, Jorge Godoy <jgo...@gmail.com> wrote:
> Em Thursday 01 November 2007 22:46:30 Roger Demetrescu escreveu:
> > Regarding the fix in URL, do you mean the URL from the browser ? That > > would require us to force a redirect. > > This isn't a problem if we want to correct page -7 to page 1, because > > we can detect it before manipulating the data.
> The question that should be asked is: Why is there a negative number there? > If it was a hand crafted URL, then a redirect is the best answer.
> It it was programmatically inserted, then a redirect might be costly, but I > still believe it is the best answer.
> I don't see a reason to have negative numbers while using paginate.
Nether me....
> > However, if we must correct page 700 to page 15, it will be after we > > have an idea of the data size... which mean we will hit the database > > if we are paginating SelectResults or Query. If we redirect the > > browser to a nice URL with page number fixed to 15, that will force us > > to hit the database again... > > Does it worth the effort ?
> I believe it does. It should never happen at first case (Why is the big > number there when the dataset isn't so big? Hand crafted URL?).
Ok... I exaggerated.. Change my example to : "correct page 16 to page 15"...
> > Using Google as an example again... if we tamper the "star" parameter > > from its URL to a value out of bound, it will adjust the data > > displayed to the 1st or last page...but the tampered parameter will > > remain in the URL... until you click on one of the pagination links..
> The problem here is that if a user cuts & paste the URL somewhere or to > someone else, then there will be the fix overhead everytime the URL is > accessed. What is more costly: fixing it once or fixing it dozens / > hundreds / thousands (think search engines...) of times?
Doing a:
if current_page > page_count: current_page = page_count
Doesn't seem to cost much... :)
And about search engines.... if my data has any possibility to be so dynamic, I wouldn't allow it to be indexed by search engine. I always hate when I search for "foobar" and google points me to a URL that doesn't have "foobar" in its content... :(
> For a hand crafted and wrong URL, I don't see a problem on making the user > wait. He should use navigational controls inside the application. If the > users need something else with more frequency then the programmer has to take > care of it. It is bad design to have users editing URLs to change behaviour > on the application.
Again, think on real live... you are paginating some volatile data (in a intranet app) and you clicked on page 300th, but now you have only 297 pages... Who matters if the URL is still showing tg_paginate_no=300 (or data_tgp_no=300) ?
Sorry Godoy, but I am -1 on raising a redirect to fix the URL... :-/
Em Saturday 03 November 2007 16:18:50 Roger Demetrescu escreveu:
> Again, think on real live... you are paginating some volatile data (in > a intranet app) and you clicked on page 300th, but now you have only > 297 pages... Who matters if the URL is still showing > tg_paginate_no=300 (or data_tgp_no=300) ?
I use transactions most of the time and PostgreSQL has MVCC, so changes outside the current transaction wouldn't affect my other transactions.
> Sorry Godoy, but I am -1 on raising a redirect to fix the URL... :-/
No problem. It was a suggestion, not anything else. :-)
> I would avoid hitting my database at all cost..
The redirect could occur before hitting the database...
On Nov 3, 2007 5:18 PM, Jorge Godoy <jgo...@gmail.com> wrote:
> Em Saturday 03 November 2007 16:18:50 Roger Demetrescu escreveu:
> > Again, think on real live... you are paginating some volatile data (in > > a intranet app) and you clicked on page 300th, but now you have only > > 297 pages... Who matters if the URL is still showing > > tg_paginate_no=300 (or data_tgp_no=300) ?
> I use transactions most of the time and PostgreSQL has MVCC, so changes > outside the current transaction wouldn't affect my other transactions.
> > Sorry Godoy, but I am -1 on raising a redirect to fix the URL... :-/
> No problem. It was a suggestion, not anything else. :-)
Phew... :)
> > I would avoid hitting my database at all cost..
> The redirect could occur before hitting the database...
For pages <= 0, yes...
For page > page_count, no... page_count is discovered hitting the database (if we are paginating DB stuff, of course)
From paginate.py:
=== if (SelectResults and isinstance(var_data, SelectResults)) or \ (SASelectResults and isinstance(var_data, SASelectResults)) or \ (Query and isinstance(var_data, Query)): row_count = var_data.count() ===
