On Mon, Dec 7, 2009 at 3:40 PM, Derrell Lipman <
[email protected]> wrote:
> 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 had considered using a timer before querying the DB, since the only
request I really need to go to the server is the very last one, but I think
this depends on a variety of things I may not be able to control - keyboard
repeat rate, etc. I may yet get around to setting that up, but would still
like a way to notify the user that something is happening. I did try
changing the display panels and calling syncAppearance(), but it seems to
have no effect - is that the 'refresh' method you mention? Qooxdoo really
seems to be "letting the dust settle" before applying any of the updates
I've set, which is pretty frustrating.
Ken
------------------------------------------------------------------------------
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
