On 08/29/2012 06:50 PM, Endi Sukma Dewata wrote:
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.
I think we are in an agreement. It's basically what I wrote in different
words. I just mentioned current size limit.
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.
2) search for record: enter filter to textbox, normal search would be used
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.
4) record still not listed: page to find the record using current paging
UI or some improved
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.
Comments below.
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.
Yes as I wrote above.
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.
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.
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.
Anyway empty rows can be also replaced by rows with huge height.
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.
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.
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).
--
Petr Vobornik
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
