[poll] how paginate should handle out of bound pages ?

18 views
Skip to first unread message

Roger Demetrescu

unread,
Oct 31, 2007, 9:26:16 PM10/31/07
to turbo...@googlegroups.com
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

remi jolin

unread,
Nov 1, 2007, 5:28:19 AM11/1/07
to turbo...@googlegroups.com
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. ?

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.
>
>

-1 should return the last page etc...
then 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.
>
>

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.
>
>

b)

Diez B. Roggisch

unread,
Nov 1, 2007, 5:31:18 AM11/1/07
to turbo...@googlegroups.com
>
> =====================
>
> [Scenario 1]: Page <= 0
>
> 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.

Diez

Jorge Godoy

unread,
Nov 1, 2007, 6:00:59 AM11/1/07
to turbo...@googlegroups.com
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.


--
Jorge Godoy <jgo...@gmail.com>

Roger Demetrescu

unread,
Nov 1, 2007, 5:13:24 PM11/1/07
to turbo...@googlegroups.com
Hi remi...

On Nov 1, 2007 6:28 AM, remi jolin <remi....@sysgroup.fr> 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. ?
>
> 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)


Cheers,

Roger

Jorge Godoy

unread,
Nov 1, 2007, 6:15:33 PM11/1/07
to turbo...@googlegroups.com
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.

--
Jorge Godoy <jgo...@gmail.com>

remi jolin

unread,
Nov 1, 2007, 7:10:37 PM11/1/07
to turbo...@googlegroups.com
le 01.11.2007 23:15 Jorge Godoy a écrit:
> 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.
>
>
Exactly :-)

Roger Demetrescu

unread,
Nov 1, 2007, 8:34:18 PM11/1/07
to turbo...@googlegroups.com
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...


So, what do you guys think about it ?

Cheers,

Roger

Roger Demetrescu

unread,
Nov 1, 2007, 8:46:30 PM11/1/07
to turbo...@googlegroups.com
Hei Godoy !!

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..


[]s
Roger

remi jolin

unread,
Nov 2, 2007, 3:39:59 AM11/2/07
to turbo...@googlegroups.com
le 02.11.2007 01:34 Roger Demetrescu a écrit:
> 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]

Eduardo Rocha

unread,
Nov 1, 2007, 8:50:32 AM11/1/07
to TurboGears
>
> [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)

> [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.
>

+1 on (b)

Eduardo Rocha

Diez B. Roggisch

unread,
Nov 2, 2007, 5:44:05 AM11/2/07
to turbo...@googlegroups.com
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?

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.


Diez

Diez B. Roggisch

unread,
Nov 2, 2007, 5:47:13 AM11/2/07
to turbo...@googlegroups.com, Roger Demetrescu

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.

Diez

remi jolin

unread,
Nov 2, 2007, 7:15:52 AM11/2/07
to turbo...@googlegroups.com
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.

Diez B. Roggisch

unread,
Nov 2, 2007, 7:55:39 AM11/2/07
to turbo...@googlegroups.com

> 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.


Diez

Roger Demetrescu

unread,
Nov 2, 2007, 8:39:52 AM11/2/07
to turbo...@googlegroups.com


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).

Thanks for your feedback !! :)

[]s
Roger

remi jolin

unread,
Nov 2, 2007, 8:50:44 AM11/2/07
to turbo...@googlegroups.com
Hello Roger,

Ok, I did not read carefully enough.


>>>>> 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.

remi jolin

unread,
Nov 2, 2007, 8:53:40 AM11/2/07
to turbo...@googlegroups.com
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.
> Diez
>
> >
>

Diez B. Roggisch

unread,
Nov 2, 2007, 9:22:57 AM11/2/07
to turbo...@googlegroups.com

> > (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.

Diez

remi jolin

unread,
Nov 2, 2007, 12:17:34 PM11/2/07
to turbo...@googlegroups.com
le 02.11.2007 14:22 Diez B. Roggisch a écrit:
>
>>> (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.
> Diez
>
> >
>

Jorge Godoy

unread,
Nov 3, 2007, 9:10:44 AM11/3/07
to turbo...@googlegroups.com
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.

--
Jorge Godoy <jgo...@gmail.com>

Jorge Godoy

unread,
Nov 3, 2007, 9:12:54 AM11/3/07
to turbo...@googlegroups.com
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.

--
Jorge Godoy <jgo...@gmail.com>

Roger Demetrescu

unread,
Nov 3, 2007, 2:18:50 PM11/3/07
to turbo...@googlegroups.com
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... :-/

I would avoid hitting my database at all cost..


[]s
Roger

Jorge Godoy

unread,
Nov 3, 2007, 4:18:54 PM11/3/07
to turbo...@googlegroups.com
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...

--
Jorge Godoy <jgo...@gmail.com>

Roger Demetrescu

unread,
Nov 3, 2007, 4:24:04 PM11/3/07
to turbo...@googlegroups.com
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()
===

[]s
Roger

Roger Demetrescu

unread,
Nov 4, 2007, 6:17:43 AM11/4/07
to turbo...@googlegroups.com

Today we have Paginate.get_href(...)

What do you think about Paginate.get_last_href(..) ?

It would render a link with page number == 'last', which would be
handled in @paginate as "current_page = page_count".

This way, we avoid exceptions on negative numbers... All zero and
negative page numbers are corrected do page 1.
All page > page_count are corrected to page_count.

And page == 'last' will be our mechanism to give the behavior you want.


Is this fine to you ? :)

Jorge Godoy

unread,
Nov 4, 2007, 6:37:03 AM11/4/07
to turbo...@googlegroups.com
Em Sunday 04 November 2007 09:17:43 Roger Demetrescu escreveu:
> This way, we avoid exceptions on negative numbers... All zero and
> negative page numbers are corrected do page 1.
> All page > page_count are corrected to page_count.
>
> And page == 'last' will be our mechanism to give the behavior you want.
>
>
> Is this fine to you ? :)

It is to me. :-) (Even though I would like to fix the URL as well -- maybe a
parameter? -- hey, don't look at me like you were mad by my insistence on
that... :-) *Sometimes* I have good reasons.)

--
Jorge Godoy <jgo...@gmail.com>

remi jolin

unread,
Nov 4, 2007, 1:46:28 PM11/4/07
to turbo...@googlegroups.com
Yes, great ;-)
> >
>

Roger Demetrescu

unread,
Nov 4, 2007, 5:57:26 PM11/4/07
to turbo...@googlegroups.com

Hahahaha... :)

Ok... give-me a good name to be used in our dev.cfg / prod.cfg to turn
on the redirect behaviour... :)


[]s
Roger

Jorge Godoy

unread,
Nov 4, 2007, 6:09:03 PM11/4/07
to turbo...@googlegroups.com
Em Sunday 04 November 2007 20:57:26 Roger Demetrescu escreveu:
> Ok... give-me a good name to be used in our dev.cfg / prod.cfg to turn
> on the redirect behaviour... :)

paginate.redirect_on_out_of_range ? :-) LOL

You don't need to have it if you don't think it will be useful. I can live
without it and I'll still use paginate :-)

--
Jorge Godoy <jgo...@gmail.com>

Roger Demetrescu

unread,
Nov 4, 2007, 7:15:24 PM11/4/07
to turbo...@googlegroups.com

Well, just because it won't be used by me doesn't mean others won't use... :)

If this feature is disabled by default, I don't mind adding it...

If anybody has something to say against this feature, say now or... ;)


[]s
Roger

Reply all
Reply to author
Forward
0 new messages