[Freeipa-devel] Paging in Web UI
Endi Sukma Dewata
edewata at redhat.com
Sat Sep 1 17:04:32 UTC 2012
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
More information about the Freeipa-devel
mailing list