[Freeipa-devel] Paging in Web UI

[Endi Sukma Dewata]

On 8/29/2012 8:49 AM, Petr Vobornik wrote:
>> Another possibility is to use VLV, but it seems to require open
>> connection too and only works with a predefined filter.
>
> Apart from the possible connection problem I think it is very usable for
> default views of search pages. User can freely page. I don't understand
> from the wiki page if it can reasonably obtain total record count.

Correction, VLV doesn't seem to require a continuous connection.

The server will return a 'contentCount' in the VLV response:
http://www.ietf.org/proceedings/55/I-D/draft-ietf-ldapext-ldapv3-vlv-09.txt

> IMO a modification of a hybrid solution may be best:
>
> When user opens page a VLV result would be shown. User can page and see
> all the data. Currently we don't support custom sorting so disability of
> custom sorting isn't an issue. With predefined sorts we can even
> improved these possibilities.
>
> If there is many records and user don't want to go through pages he will
> use search. If the search string is good he should fit to search limit
> so I wouldn't use paging at this moment. If not the case and he really
> don't know how to improve the filter he should have option to enable
> paging (current implementation) and go through the records by hand. Such
> record set should fit to limit of 2000 records. If not the filter is
> really bad.

The thing is the filter is only used on certain attributes only. For 
example I have a user with full name "Test User". Searching the "Test 
User" in the filter doesn't return anything because the server doesn't 
search the cn or displayName attributes. In that case I'd have to search 
with first name or last name only, which may return too many results.

> If we don't want to implement VLV or until that time I would set
> not-paging as default setting.

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.

>> Agreed, but if we implement the single continuous page I described in
>> the earlier email the page size won't be much of an issue anymore.
>>
> It may matter. For example when testing Web UI permissions. It often
> requires to navigate to the last page. I can enter the number directly
> and press enter or extend it for times (hypothetically) but I would
> rather see those 90 permissions right away because I can be at the list
> end in 0.5s.

If we use a continuous page we can use a bigger default page size, say 
100 entries. We probably could optimize it such that if you scroll 
directly to the bottom it will load just the last page. We probably 
could also combine it with initial non-paging search like above, so 
you'll need to click "See more results...", then the page will extend 
and you can scroll to the last entry.

> We can also improve pager to offer some subset of pages. For example:
>
> First Prev 22 23 *24* 25 26 Next Last Page [   ]
> where 24 is current page.

Yes, that will work too.

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

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.

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.

-- 
Endi S. Dewata