On Mon, Dec 7, 2009 at 15:28, Ken MacDonald <[email protected]> wrote:
> I have a qx.ui.table.Table, single select, with 100's of entries. As I
> select a new entry, details of that entry are queried from our DB server,
> and displayed in two other panels on the page; one is another Table, and the
> other is a qx.ui.embed.html. That works well.
>
> However, if I go to the original table, and hit/hold the down-arrow
> through, say, 100 entries, the DB gets WAY behind, and the detail displays
> just "freeze", usually at about the location where I started down-arrowing.
> After a long wait with no apparent activity, the displays updates to the new
> entry 100 down.
>
> I would like to know if there is a way to display some type of progress
> indicator so users don't think the display has just died. I've tried
> updating the html panel (with "skipping entry # 582" etc.) and calling
> syncAppearance(), clearing the html panel, creating ANOTHER html panel, but
> action seems to be frozen no matter what I do - these things all work in
> Firebug, of course.
>
So each of those rows that are being quickly passed by are generating a
request to the server. The problem is determining how many of them can
simply be discarded rather than passed to the server. You clearly need
enough of them to actually occur to fill the final visible table rows. If
there are no other side effects that you depend on, all of the intervening
ones could be discarded.
One way to solve this, that may point you towards some reasonable solution,
is instead of issuing your remote request immediately upon selection of a
row, add the request to a queue and start a timer with a short interval.
Each time you get a new selection, add the request to the queue and reset
the timer to so that short interval so that it doesn't fire at its original
time, but instead some slightly later time. Your timer keeps getting
suspended and suspended until finally the arrow key is released. You can now
discard all but the most recent N requests, and issue each of them to your
server. (In fact, there's some method call in Table that would cause a
refresh. I don't recall at the moment what it is, but if you find that, and
the queue is "long" enough by whatever definition of "long" you decide, you
could just discard all of those queued requests and call the method that
tells the table to refresh itself.
I haven't clearly thought out this whole concept, but hopefully it gives you
some ideas.
Cheers,
Derrell
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
