Hi Sven, I am absolutely sure that Trinidad calls isRowAvailable() on rows that are not visible! To be more specific: isRowAvailable() is called on all rows that show up in the combobox where you can choose the range. I can confirm that isRowAvailable() is not called for rows that are beyond the "more..." item in the combobox. Perhaps that is what you mean to say?
I looked again at the code example on the wiki. It turns out you are right about not calling the database more than once, since the page is stored as a member of DataPage. (I overlooked that the first time. Sorry for that.) That means the wiki solution should work, even while Trinidad keeps calling isRowAvailable() on invisible rows. (Which is still wrong in my opinion...) So I'll give the Wiki solution a try. I'll let you know the outcome... Best regards, Bart Kummel "Rottstock, Sven" <[EMAIL PROTECTED]> wrote on 17-01-2008 14:58:15: > 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
