By the way - you should set the rows attribute in the table and you should keep it synchronize with the pageSize parameter in the constructor of PagedListDataModel. So Trinidad will call isRowAvailable() only for the visible row entries. Trust me - i have it also implemented and it works great ;-)
-----Ursprüngliche Nachricht----- Von: Rottstock, Sven [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. Januar 2008 14:50 An: MyFaces Discussion Betreff: AW: AW: [Trinidad] Pagination in a <tr:table>? No it is. You have an object that represent a subset of fetched entries (DataPage). Furthermore the total count of entries is also stored in this object. If Trinidad is calling isRowAvailable then you gets the total count of entries in your database and compares it to your current rowIndex: public boolean isRowAvailable() { DataPage<T> page = getPage(); if (page == null) return false; int rowIndex = getRowIndex(); if (rowIndex < 0) { return false; } else if (rowIndex >= page.getDatasetSize()) { return false; } else { return true; } } Only getRowData will do any database transactions if a desired rowIndex is not in a subset. Regards, Sven ________________________________ Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. Januar 2008 13:22 An: MyFaces Discussion Cc: MyFaces Discussion Betreff: Re: AW: [Trinidad] Pagination in a <tr:table>? Hi Sven, Thanks for your reply. I think the solution on the wiki does not solve my problem. As Renzo stated in his reply, the real problem is that the Trinidad table is calling isRowAvailable() for rows that are not visible. (Perhaps we should file a bug report?) The solution on the wiki does go to the database too when isRowAvailable() is called, just like Trinidad's own CollectionModel, right? I will try implementing my onw CollectionModel, as Markus proposed. (Markus' reply is not included in the history below, sorry for that.) I'll let you all know if I succeed. Best regards, Bart Kummel "Rottstock, Sven" <[EMAIL PROTECTED]> wrote on 17-01-2008 13:08:45: > Please have a look at: > http://wiki.apache.org/myfaces/WorkingWithLargeTables > > You can also use it with Trinidad. > > Regards, > > Sven > > Von: Renzo Tomaselli [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 17. Januar 2008 12:16 > An: MyFaces Discussion > Betreff: Re: [Trinidad] Pagination in a <tr:table>? > Bart, I noticed this behavior as well, but I was unable to collect > any reply from this list. > The basic issue is that the page navigator calls isRowAvailable() in > the data model many times just to setup a predefined number of > ranges in the widget, where the user can select from. These calls in > turn endup in probing the database with searches, and here > performance drops down. > This behavior occurs if you declare in advance the overall dataset size. > If this is undefined (-1), then the widget contains one range plus "more ...". > I found that the second solution avoids a lot of isRowAvailable() calls. > And you cannot be lazy in answering this call: if your model answers > yes, while returnin null at the getRowData(), you end up with a blank row. > In any case a significat performance gain is achieve by caching a > page, saving/restoring it across requests. Then reload the cache > before rendering, if the underlying model might have changed. > Hope it helps. > > -- Renzo > > [EMAIL PROTECTED] wrote: > > Hi List, > > It's fairly easy to implement pagination with a <tr:table> > component. Just set the "rows" and "first" attributes and you're > done. But it turns out that the pagination is not implemented very > smart. Let me explain my case... > > I have a database with some very large tables (10000 to 100000 > records per table). The database is (sadly enough) not too fast. So > to make the user interface responsive to the users, it is very > important that only the data that is displayed is fetched from the > database. Therefore, I implemented a "lazy list", as suggested on > http://www.ilikespam.com/blog/lazy_list. I expected to get much > better performance, but this did not happen. I added some logging to > the lazy list to see what's happening. It turns out that the table > is prefetching a lot more rows that the ones that are displayed initially. > > I did set the "rows" attribute to 10, but it seems the table is > fetching about 300 rows at a time. (This takes more than a minute > due to my poor performing database...) This can actually be a nice > feature, since the user can browse very fast through the next 300 > records... once they are loaded. The problem is, however, that the > table does not get rendered until the fetching of those 300 records > is finished. > > So my question is: is there a way to configure the fetching strategy > of the table component? Is it possible to give rendering a higher > priority than prefetching, for instance? Or can I configure how many > rows are prefetched? > > Thanks in advance for your help! > Best regards, > Bart Kummel
