[Freeipa-devel] Paging in Web UI

[Endi Sukma Dewata]

On 8/31/2012 9:54 AM, Petr Vobornik wrote:
>> How about this, when you open the search page for the first time it will
>> do a regular search, no paging. Instead of showing the paging controls
>> (Prev & Next buttons) we show "See more results..." If you click that it
>> will rerun the search with paging (which will give us the total number
>> of entries) and show the paging control.
>
> I think we are in an agreement. It's basically what I wrote in different
> words. I just mentioned current size limit.

Let me try to summarize. We are dealing with 3 different aspects:

In the UI we will use 2 levels of search pages. In the initial page we 
will do a quick search to get a partial result. If you want to see the 
full result you have to click 'more'. The full result can displayed 
using multiple pages (like the current implementation) or single 
continuous page (the one I'm suggesting as an alternative solution). The 
multi-page solution will have paging controls (prev & next buttons, page 
links), the single-page won't.

Between the UI and the server the we can use 2-step operation (UI does 
the paging, it gets the pkey list first then gets the visible entries, 
this is the current implementation) or 1-step operation (server does the 
paging, UI gets the entries one page at a time). Any of these options 
can be used to implement either multi-page or single-page solution above.

In the server we can retrieve the LDAP data with a simple search 
(default size limit is 100, can be increased up to 2000), with SPR 
(unlimited size, see below), or with VLV (unlimited size, but requires 
predefined filter). Any of these options can be used with either 1-step 
or 2-step operations to get the pkey list or the entries.

> User workflow when searching for record (the same thing reworded):
> 1) open search page: VLV or normal search with empty filter
>    1a) when VLV: user would see paging ui
>    1b) when normal search: not sure if to show 'see more results' link
> for switching to paging. For smaller setups (<2000) it might be there,
> for larger rather not - pkey list would be truncated.

For the initial page if we use the simple search (1b) the UI will look 
like this:
http://edewata.fedorapeople.org/images/paging1.png

Here the UI will get up to 100 entries (default size limit), then it 
displays them in a single page. There will be a scroll bar to scroll 
through these 100 entries, but it will not pull more entries. To see 
other entries you click 'more', it will go to full result (3) below. The 
simple search doesn't return the total number of entries, so we can't 
show the paging controls.

If we use SPR or VLV in the initial page we will know the total number 
of entries, so we don't really need an initial page, we can use the same 
page as the full result (3) below. Not sure about pros & cons of using 
SPR/VLV in the initial page, probably they will consume more server 
resources compared to simple search.

> 2) search for record: enter filter to textbox, normal search would be used

This is the same as (1b) except that in (1b) the filter is empty. 
Similarly, if the entry you're looking for is not there, you can click 
the 'more' button to see the full result (3).

Here we can also use SPR, but not VLV because VLV filter is fixed in the 
VLV configuration. I'm not sure if we can apply LDAP filter on top of 
VLV filter.

> 3) record not listed: switch to paging by clicking on 'see more results'
> Paging should be OK because most likely we would get less than 2000
> records. Otherwise filter should be improved. I guess we can't go around
> this unless we increase the limit or use other mean of paging.

According to this page we can use the nsslapd-pagedsizelimit to remove 
the global size limit on SPR:

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html#Setting_Resource_Limits_Based_on_the_Bind_DN-Setting_Resource_Limits_Using_the_Command_Line

So with SPR the server we can get the full result, one page at a time, 
no more 2000 entry limitation.

If we use the multi-page solution it will look like this:
http://edewata.fedorapeople.org/images/paging2.png

Currently we use 20 entries per page. We can change that to 100, same as 
the default search limit, so the transition from the initial page to the 
full result will be seamless.

Both SPR and VLV will return the total number of entries, so we can show 
the paging controls. We can use simple search too (like the current 
implementation) but it will be limited to 2000 entries.

> 4) record still not listed: page to find the record using current paging
> UI or some improved

There's no need for (4) because we can get all entries with SPR or VLV.

>>> Regarding the continuous paging: I would extend the page by clicking at
>>> a bar at the end of the list and/or by mouse-scrolling at the end of the
>>> list?
>>
>> Ideally the scroll bar size should correspond to the visible part of the
>> entire page. So you should be able to go anywhere in the entire page by
>> moving the scroll bar around (either by keyboard, mouse click, mouse
>> drag, or mouse scroll). In this case no need to extend the page.
>> The thing is that we might have to create a table with many empty rows,
>> which could be big, and populate them if they become visible. Maybe
>> there's a way to avoid creating empty rows, we'll need to investigate.
>
> Did you meant by 'continuous paging' this solution or the one when you
> click on 'see more results' (or scroll to last 10% of a scrollbar) and
> it would show you next page? I originally understood it as the latter
> but now I'm not sure.

There are several variations for the single-page solution, the first one 
will look like this:
http://edewata.fedorapeople.org/images/paging3.png

It looks like a single page, but the entries are pulled one page at a 
time. Suppose we have 5000 entries total, initially we'll show 100 
entries. The rest are virtual entries which will be represented as empty 
rows (or one big row). If you scroll down it will calculate the new page 
number, then it will pull the entries for that page and populate the 
empty rows. To save memory, rows that are not visible can be made empty 
again.

> This solution seems challenging to implement right. I'm also not sure
> how usable it is because I don't remember if I ever used it somewhere.

Yeah, it could be complicated to implement.

> Anyway empty rows can be also replaced by rows with huge height.

Right. But if we jump around to random pages we may have multiple 'big 
rows' that need to be maintained.

>> Alternatively we could do like image search on bing.com. If you bring
>> the scroll bar say within 10% from the bottom it will load the next
>> page. The thing is it will load the page sequentially, and if you
>> continue to the bottom you'll end up with a very big table.
>
> I like this with the Prev extension mentioned below.

This is another variation of the single-page solution, it will look like 
this:
http://edewata.fedorapeople.org/images/paging4.png

The difference is we don't create 'big rows', but if you scroll near the 
bottom it will pull the next page and append the entries at the bottom 
and we keep the old entries at the top. The drawing shows 20 entries, 
but we can change it to 100.

>> Another possibility, we can use the top 10% of the scroll bar as a Prev
>> button, and the bottom %10 as the Next button, and we remove the pages
>> that aren't visible anymore. But this is not much different than the
>> current implementation, only different presentation.

This is yet another variation of the single-page solution. It's similar 
to the previous one, but here we don't keep the old entries at the top. 
So if you go near the top it will pull the previous page and prepend the 
entries at the top.

These last two options will be more limited than the current 
implementation because you can't jump to random pages, unless we make it 
such that it keeps scrolling as long as you keep the scroll bar near the 
top/bottom and only pull the page if you release it. We will also need a 
way to show where we are in the database.

> I can image to use each of these 3 solutions for enabled paging. Also
> switching between second and third solution might be configurable.
>
> Anyway. First I would like to make paging/not paging configurable and
> switchable when needed. Then we can proceed to improving paging ui
> (better pager, continuous paging and such).

Yes, in other words it will be the switch between the initial page and 
the full result.

-- 
Endi S. Dewata