On 11/19/2014 09:49 PM, Robert Collins wrote:
On 20 November 2014 13:43, Jay Pipes <[email protected]> wrote:
On 11/19/2014 07:32 PM, Michael Krotscheck wrote:
Jay-
My own UX tests have demonstrated a need for both page jumping, and
being able to communicate to a user where they are in their list. I'd be
happy to show you the videos if you have a few hours.
I don't have a few hours, no. :) But, what use case does jumping to page 7
of some results listing fulfill?
For one, remembering where you were and coming back to it (more or less).
Sorry, I don't get this at all. I have never, once, wanted to coming
back to some random page of results. I often want to come back to a
specific record, but that's not what we're talking about here.
I can think of no time in my life that I've thought to myself "Oh, you
know, I really should go back to page 17 of my Google search results for
'frobnozzle'". It just isn't a valid use case, IME.
Jumping by batch index is cheap compared to the proposed
clone-the-result-set-ids thing, and IME useful enough that I'd be
annoyed at a system without it.
What does "jump to page 17" give you -- usefulness-wise -- over seeing
that there is a) X number of results in total and/or b) there are more
results to page through?
@Michael - I suggest just using a simple stable batch marker - e.g.
the unique key of the edge of the batch - which is stable enough to
handle inserts and deletes without double-showing or skipping rows.
That's what already exists in olso.db.utils.paginate_query(). The marker
is the unique key of the edge of the batch.
Best,
-jay
_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
