From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: GSoC: Adding a web interface similar to the Hydra web interface Date: Fri, 6 Jul 2018 11:58:26 +0200 Message-ID: References: <87tvqxy4i9.fsf@elephly.net> <87in78hxo2.fsf@elephly.net> <878t7xb58o.fsf@elephly.net> <874lijbqvf.fsf@elephly.net> <20180606200210.7a9c4dd6@scratchpost.org> <20180612183504.2621cefa@scratchpost.org> <8736xrd64y.fsf@elephly.net> <8736x8ype9.fsf@gnu.org> <20180705102753.6bc57971@scratchpost.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000047a465057051b563" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbNVh-00080f-O1 for guix-devel@gnu.org; Fri, 06 Jul 2018 05:58:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbNVg-0001Er-Iy for guix-devel@gnu.org; Fri, 06 Jul 2018 05:58:41 -0400 Received: from mail-io0-x22a.google.com ([2607:f8b0:4001:c06::22a]:36862) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fbNVg-0001Cg-AW for guix-devel@gnu.org; Fri, 06 Jul 2018 05:58:40 -0400 Received: by mail-io0-x22a.google.com with SMTP id k3-v6so10359332iog.3 for ; Fri, 06 Jul 2018 02:58:40 -0700 (PDT) In-Reply-To: <20180705102753.6bc57971@scratchpost.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: Guix-devel , Tatiana Sholokhova --00000000000047a465057051b563 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Danny Milosavljevic ezt =C3=ADrta (id=C5=91pont: 2= 018. j=C3=BAl. 5., Cs 10:28): > Hi Tatiana, > > On Wed, 4 Jul 2018 22:54:46 +0200 > Tatiana Sholokhova wrote: > > > If we want to maintain a link to > > the previous page we have to filter the database table entries with to > > types of filters: one with lower bound on the id, and the other with th= e > > upper bound. > > Yeah, I know what you mean. > > I'd suggest one of the following alternatives for implementing "Previous > page": > > (1) Remember all the page boundaries in the query string (or maybe hidden > form elements). So instead of finding out where the beginning of the > previous page was all over again just remember it from before. > (2) Reverse the ordering in the query and the boundary check and run > the query, reverse the result of the query. Handle finished result as > before. > (3) Just use the browser's back button. In fact, you can just put a > "Previous" link that presses the back button via Javascript for the time > being. > > I suggest (3) - and implement one of the others later. > > I agree that going with (3) now makes sense. The most flexible solution i= s (2). I usually do that, as it does not rely on having the earlier pages seen. I usually abstract this away in a cursor, which has the first, the last, the current page first and last ids, and a gotofirst, gotolast, next and previous operators.WDYT? > > The current implementation of pagination works correctly but it does no= t > > support link to the previous page (first, and next only). > > Cool! > --00000000000047a465057051b563 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= Danny Milosavljevic <dannym@sc= ratchpost.org> ezt =C3=ADrta (id=C5=91pont: 2018. j=C3=BAl. 5., Cs 1= 0:28):
Hi Tatiana,

On Wed, 4 Jul 2018 22:54:46 +0200
Tatiana Sholokhova <tanja201396@gmail.com> wrote:

> If we want to maintain a link to
> the previous page we have to filter the database table entries with to=
> types of filters: one with lower bound on the id, and the other with t= he
> upper bound.

Yeah, I know what you mean.

I'd suggest one of the following alternatives for implementing "Pr= evious page":

(1) Remember all the page boundaries in the query string (or maybe hidden form elements).=C2=A0 So instead of finding out where the beginning of the<= br> previous page was all over again just remember it from before.
(2) Reverse the ordering in the query and the boundary check and run
the query, reverse the result of the query.=C2=A0 Handle finished result as= before.
(3) Just use the browser's back button.=C2=A0 In fact, you can just put= a
"Previous" link that presses the back button via Javascript for t= he time being.

I suggest (3) - and implement one of the others later.

=
I agree that going with (3) now makes sense. = The most flexible solution is (2). I usually do that, as it does not rely o= n having the earlier pages seen. I usually abstract this away in a cursor, = which has the first, the last, the current page first and last ids, and a g= otofirst, gotolast, next and previous operators.WDYT?
> The current implementation of pagination works correctly but it does n= ot
> support link to the previous page (first, and next only).

Cool!
--00000000000047a465057051b563--