Hi Yee,
Yee CN wrote:
Hi Simon,
I think there is a further problem. The dataScroller 'knows' the number of
records - presumably by doing a datalist.size(). That is going to be a
problem for large datasets - we don't know the size without traversing the
whole dataset and constructing the datalist.
Well, in that case you're definitely going to have problems with any
scroller component that offers "last" or numbered page options :-) But I
don't think that it is mandatory for the dataScroller to provide those
options to the user is it?
Of course, while dataModel.size() is used by the datascroller, the
DataModel implementation doesn't have to return internalList.getSize()
does it? I'm planning to have a separate field for the actual dataset
size in my custom DataModel class, separate from the small subset of
data currently held.
Having to bind the dataTable to a List is also problematic. We really do not
want to construct a List for large dataset.
You need to provide *some* kind of collection to the dataTable. What's
the problem with passing it a list of 10 objects representing rows
1000->1010 of the dataset?
I think the dataTable in ASP.Net is more practical. It can bind to a
DataReader object, which I think is implemented as an ODBC curser. The
programmer can fast forward the datareader to a particular point, and the
dataTable will pick up the required number of records from that point for
its display.
Isn't the DataModel exactly the same as this "DataReader" class? It has:
setRowIndex
getRowData
where getRowData has to return the object at the current index offset.
Nothing anywhere states where or how it gets that data.
The table is going to simply call:
setRowIndex(1000);
getRowData()
setRowIndex(1001)
getRowData()
etc
Ok, this is a little less elegant than if the DataModel had a "getNext"
method, but the two are effectively the same aren't they?
The dataScroller has to be completely independent from the datalist and
dataTable as well. By that I mean it should not have to work with a 'real'
datalist or dataTable. Its purpose is to notify the change in page index. It
is up to the programmer to specify the datalist size, the current page index
and number of records per page.
Well, the programmer can specify the datalist size by controlling what
DataModel.getRowCount returns, and controls the number of records on the
page by defining
<t:dataTable rows="#{myBean.rowsInTable}">
The current page index is automatically set, but that seems to me to be
actually under user control.
So for the moment, it seems to me that the way .NET and JSF work with
these datasets is actually quite similar.
BTW, I got distracted by some work on MyFaces documentation, so haven't
made much progress on my implementation of a custom ListDataModel class,
but it looks like Mario is using exactly this approach which is very
encouraging.
Cheers,
Simon
