We just did that for a table that can contain thousands of rows. What
we did was similar to what you have done but with the following changes:
* A custom TableDataProvider that implements TableDataSorter and
TableDataFilter interfaces. If the TableDataProvider is the same
instance as the TableDataSorter, then the underlying
infrastructure will never call the "sort" method on the
TableDataSorter and will assume that the rows are returned in the
correct order. Similar with the TableDataFilter. If the
TableDataProvider is the same instance as the TableDataFilter,
then the "filter" method will never be called because the
assumption is that the rows are filtered before being returned.
* Our TableDataProvider only ever returns one page of rows. This
means that the paging buttons are never show.
* Our TableDataProvider is derived from ObjectListDataProvider.
This allows us to change the list of rows that are being provided
by setting a new list.
* We added paging images to the footer action facet of the table.
These are tied to actions in our backing bean which will perform a
query and call "set:List" on our TableDataProvider.
* Since our TableDataProvider implements "TableDataSorter", it's
"setSortCriteria" method will be invoked when the sorting is
changed by the user. We capture the "SortCriteria" objects and
use these in our query (order by clause) to return the rows in the
correct sorted order.
* Since our TableDataProvider implements "TableDataFilter", it's
"setFilterCriteria" method will be invoked when the filtering is
changed by the user. We capture the "FitlerCriteria" objects and
use these in our query (where clause) to return the rows with the
filters applied.
The one thing that we do not do is to support "Page X of Y" and the
associated "Goto Page" functionality. Figuring out how many pages of
records there are, pretty much requires a complete read through our
database which would be a performance killer.
It really is a pain that the infrastructure calls "getRows" to determine
the paging buttons and the Goto functionality. This requires all of the
rows to be available which with thousands of rows is not practical. So
we went with our own paging controls in the table footer action facet.
jpsfranks wrote:
> Hello,
>
> I've been trying to use the woodstock table component with a result
> set whose size is initially indeterminate. I'm hoping to render the
> first page of data initially, and have additional pages become
> accessible as the data for them is retrieved.
>
> Does anybody have any ideas on how I might go about doing this, or
> even if it's a good idea to use the table component for this?
>
> I've gotten most of the way there by doing the following:
>
> * Implementing a custom TableDataProvider for my data which
> returns row counts according to the currently available rows.
> * Implementing a custom TableDataSorter that re-runs my back end
> query with the new sort, and always returns the first page's
> RowKeys (basically swapping the first page within the data
> provider to match the new first page for the sort, since you
> can't render in sorted order from memory when it's not all loaded).
> * Using Javascript and AJAX to enable/disable the next/last page
> buttons as appropriate depending on what pages are available.
>
>
>
> It seems a bit crazy, but everything pretty much works. The last
> problem I'm dealing with is that when the next/last page button is
> clicked the first time, the table can only advance to a page that was
> available when the table was first rendered, even if there's more data
> accessible. I've tried clearing out the cached RowKeys in my
> TableRowGroup, but the initial RowKeys from the first rendering are
> restored from state on any paging action, and only the pages
> represented by those first RowKeys are available before the table is
> re-rendered once.
>
> So what typically happens is that the table will render initially with
> two pages available. When the last page is available and I enable the
> last page button, clicking it only takes you to the second page (the
> table was initially rendered with two pages' worth of RowKeys). After
> that all pages are available and everything works fine, it's just the
> first paging action doesn't work quite right.
>
> I have considered using custom paging controls, and may try that route
> if I can't figure out how to work with the built-in controls.
>
> Thanks for any ideas.
> ------------------------------------------------------------------------
> View this message in context: Table with incomplete data?
> <http://www.nabble.com/Table-with-incomplete-data--tp14284585p14284585.html>
> Sent from the Project Woodstock - Users mailing list archive
> <http://www.nabble.com/Project-Woodstock---Users-f26168.html> at
> Nabble.com.