We're using a complex solution for this problem: dynamic service-callback and cached data with a new read-only List-implementation.
Here are some information about it: http://sebcsaba.fw.hu/scrollablelist.html BR, Csaba -----Original Message----- From: Yee CN [mailto:[EMAIL PROTECTED] Sent: Friday, November 25, 2005 1:32 PM To: 'MyFaces Discussion' Subject: RE: dataTable, t:dataScroller and large datasets Hi Simon, My problem is really that I still know not enough about JSF, DataModel, dataTable, dataScroller and how to make then dance together. Anyway I found a pretty good article today: http://blogs.sun.com/roller/page/tor?entry=data_but_not_database_data I hope more documentation can be written to help out new comers like me. Would appreciate if you can share you code when you got it done. Many thanks in advance. Regards, Yee p.s. MS dataReader is actually much close to a ODBC cursor. You definitely not going to get 3tired architecture if you use it in the web tier! -----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Friday, 25 November 2005 11:56 AM To: MyFaces Discussion Subject: Re: dataTable, t:dataScroller and large datasets 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
