Paging HTML viewer

[dhoffer]

I'm using the HTML widget to render some dynamic conversation logs.
The problem is these logs can grow over time and add lots of DOM
Nodes. I'm wondering if someone has made some sort of a paging HTML
viewer? Currently I wrap the HTML widget in a GXT
VerticalLayoutContainer with vertical scrolling, but could have used
GWT ScrollPanel I presume. So I'm only showing a portion of the HTML
at a time anyway so seems like paging would be an ideal solution.

One trick, it seems, is that you have to calculate how big (tall) each
portion of the HTML is so you know what portion to show when
scrolling. This seems like it would be very useful general purpose
GWT widget so I'm wondering if someone has made something like this
already.

Thanks,
-Dave

[Jens]

You don't have to know how tall each HTML portion is. You just need to know when to load the next page of data and that would be if your scroll position nearly reaches the bottom of ScrollPanel.

Its pretty similar to what you can see here (see ShowMorePagerPanel.java): 

http://gwt.google.com/samples/Showcase/Showcase.html?locale=en#!CwCellList 

So you just need a ScrollPanel with a ScrollHandler attached that notifies you when to load/render the next page of log entries because the user has nearly scrolled to the end of the displayed widget.

I have implemented a list some time ago (before cell widgets) that required fixed height list entries and only rendered the list entry widgets when they are actually visible to the user. So at any time during scrolling the DOM only contained that much elements needed to fill the visible area. Scrolled out items were removed from DOM while scrolled in items were attached constantly while scrolling. The math wasn't that complicated and it works pretty well but because of the constantly deleting and adding of DOM elements while scrolling we had some hiccups in older IE's when scrolling fast through the list. But we could easily scroll through thousands of list entries while only having ~40 DIVs (depending on list height and fixed list entry height) to represent them.

Although it worked I think I wouldn't do it again that way unless you have some memory constraints (mobile devices) and don't want to have that many invisible DOM elements laying around (on the other hand constantly updating the DOM can cost more battery power on mobile devices). 

Having a ScrollHandler that notifies you when reaching the end of the list is a simpler solution.

-- J.

[dhoffer]

Thanks much I'll have a look at that example in more detail to see if
I can make that work for what I need to do.

My case is sort of the reverse of that...in that by default the scroll
is at the bottom...new messages go to the bottom of the list...so it's
like a 'tail' viewer always watching the latest messages. So I need
to remove the old messages and only show them if they scroll up to see
them.

I have something partly working...I remove old DOM elements after a
certain point and then put them back when they scroll to the top. But
I have two problems to resolve:
1. The scrollbar 'looks' wrong because since I take out old messages
the scrollbar thinks the client height is always small so the
scrollbar thumb is way too big and doesn't reflect the large content
the client really can have.
2. Because of #1 I don't have a good way to tell the user there are
more old messages that could be added to the view...currently I just
re-add 10 old messages every time they scroll to the top but that
needs improvement.

It's like I really need a virtual scrollbar that I position and
control is size and position based on the actual message content I
have vs. what the HTML widget is currently showing.

Regarding performance, I think I do need to implement this because I'm
seeing very bad memory usage with thousands of DOM nodes...power
considerations don't matter much to me...as this will be run in
desktop browser.

Thanks,
-Dave

On Aug 14, 9:16 am, Jens <jens.nehlme...@gmail.com> wrote:
> You don't have to know how tall each HTML portion is. You just need to know
> when to load the next page of data and that would be if your scroll
> position nearly reaches the bottom of ScrollPanel.
>

> Its pretty similar to what you can see here (see ShowMorePagerPanel.java):http://gwt.google.com/samples/Showcase/Showcase.html?locale=en#!CwCel...

[Jens]

I don't know your app and requirements but if you have so many log entries to show, does scrolling still makes sense? I mean at some point the scrollbar does not shrink anymore and scrolling becomes a pain if you have so many items in your list. As an user I would never search through them using scrolling but instead expect and use a search/filter widget to get the log information I am looking for. Or you make your live log viewer only contain the last 100 items and provide a CellTable/DataGrid which is no live log view but instead displays all logs since now() and uses paging so you can easily go back in time.

Nevertheless, in my list I have used an AbsolutePanel inside the ScrollPanel and set its height to <num items> * <fixed item height> and while scrolling I have calculated absolute positions for the items. Without fixed height you have to wait until an item is rendered to get its offset height which would cause bad performance I think.

-- J.

[dhoffer]

Yeah, I understand your point. I think in my case scrolling is the
most natural behavior. Your right the scrollbar thumb stops
shrinking...although not ideal so they don't get a visual feedback of
how large the real message queue is...I think I can live with that.
It's a lot better than the browser crashing because it can't handle
the DOM size. (Some sort of a virtual/custom scrollbar could solve
this.)

I have the HTML DOM element caching working quite well...its
configurable but I default to start the cache at 2x the visible
size...then as they scroll up I slowly pop the cache back on the
DOM...then put back in the cache on the way back down. In all ways
(except one) scrolling is seem-less, including using the mouse
scrollwheel, you can't tell I'm adding/removing from the DOM...the
exception is if your moving the scrollbar thumb directly...then that
will be a bit jumpy...especially if a large message was added/removed
from the DOM. I'm not sure how to handle this case...if I can at all.

The only thing I haven't figured out yet is how to handle mouse
selection ranges. They could make a large text selection where I have
moved some of the DOM entries in their selection to the cache. I just
posted another message about this. Basically I need a way to clear
their first click point in the HTML widget.

(We will handle real text searching differently...we will auto store
these message streams to a database and support full text searching.
But that's out of scope for now.)

Thanks,
-Dave