Re: T5: Grid#setupDataSource and GridDataSource
2009-06-25 Thiago H. de Paula Figueiredo: > 2009/6/25 Przemysław Wojnowski : > > My point is that the current implementation of Grid#setupDataSource() > > uses getAvailableRows() to calculate exact values for start and end > > indices. Shouldn't this be responsibility of GridDataSource? > > Nice points in the whole message. :) > One solution would be to create another interface, because Grid needs > to know the number of available rows (regardless if before or after > prepare()) and changing GridDataSource now would break backward > compatibility quite badly. > > IMHO there is no need for special value. It's just matter of the current > > implementation of Grid#setupDataSource(). > > You're suggesting the reversal of invokating order of prepare() and > getAvailableRows()? I don't see any way of Grid working without > getAvailableRows(), as it's needed to handle paging. > I think i was misunderstood. I don't want to change any interface, especially GridDataSource. I'm just writing about current (Tapestry 5.2.0-snapshot) implementation of one method: Grid#setupDataSource(). The source code for this method is as follows: --- code --- void setupDataSource() { // TAP5-34: (...) cachingSource = new CachingDataSource(source); int availableRows = cachingSource.getAvailableRows(); if (availableRows == 0) return; int maxPage = ((availableRows - 1) / rowsPerPage) + 1; // This captures when the number of rows has decreased, typically due to deletions. int effectiveCurrentPage = getCurrentPage(); if (effectiveCurrentPage > maxPage) effectiveCurrentPage = maxPage; int startIndex = (effectiveCurrentPage - 1) * rowsPerPage; int endIndex = Math.min(startIndex + rowsPerPage - 1, availableRows - 1); dataModel = null; cachingSource.prepare(startIndex, endIndex, sortModel.getSortConstraints()); } --- code --- Here getAvailableRows() is used only to calculate start and end indices. But their exact values (taking into account decreased number of rows) can (maybe should?) be calculated in implementation of GridDataSource and then implementation of Grid#setupDataSource() could look like this: --- code --- void setupDataSource() { cachingSource = new CachingDataSource(source); int startIndex = (getCurrentPage()-1) * rowsPerPage; cachingSource.prepare(startIndex, startIndex+rowsPerPage, sortModel.getSortConstraints()); } --- code --- Grid still uses getAvailableRows() but not in setupDataSource() method, and not before prepare(). Maybe I misunderstood something or not seeing something. In that case I would like to know what. :-) Best regards and thanks for response! Przemysław Wojnowski - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
2009/6/25 Przemysław Wojnowski : > My point is that the current implementation of Grid#setupDataSource() > uses getAvailableRows() to calculate exact values for start and end > indices. Shouldn't this be responsibility of GridDataSource? Nice points in the whole message. :) One solution would be to create another interface, because Grid needs to know the number of available rows (regardless if before or after prepare()) and changing GridDataSource now would break backward compatibility quite badly. > IMHO there is no need for special value. It's just matter of the current > implementation of Grid#setupDataSource(). You're suggesting the reversal of invokating order of prepare() and getAvailableRows()? I don't see any way of Grid working without getAvailableRows(), as it's needed to handle paging. -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
Dnia 2009-06-24, śro o godzinie 12:19 -0300, Thiago H. de Paula Figueiredo pisze: > > Why Grid#setupDataSource() is calculating endIndex and not allowing for > > GridDataSource to do it? Why GridDataSource#prepare method have > > startIndex and endIndex parameters and not offset/limit pair? > > As offset = startIndex and limit = endIndex - startIndex + 1, I think > their interchangeable for most scenarios. > > > I'm asking, because if GridDataSource could calculate endIndex (or use > > limit instead) for itself, then there would be no need to call > > getAvailableRows() before prepare(), which is a problem (at least IMHO). > > I guess getAvailableRows() is used for calculating the number of pages > and then display the pager. When pager is used, then GDS#prepare() was already called, so getAvaialbleRows() can return correct value. My point is that the current implementation of Grid#setupDataSource() uses getAvailableRows() to calculate exact values for start and end indices. Shouldn't this be responsibility of GridDataSource? Grid#setupDataSource() could pass just "logical" (exact available rows would be calculated by GDS) values calculated as I wrote in previous post. IMHO this would also allow for GDS to handle rows deletions for itself. > > > This would allow for single-call (those which receive number of > > available rows, columns definitions, and columns values in one expensive > > call) datasources to work. > > Please file a JIRA about this. Maybe we could use some special return > value in GridDataSource.getAvailableRows() to indicate that it is not > available yet and then call it again after GridDataSource.prepare(), > thus solving your problem. IMHO there is no need for special value. It's just matter of the current implementation of Grid#setupDataSource(). For now, to make Grid working with single-call GridDataSource, I had to copy Grid.java only to replace setupDataSource(). Best regards, Przemysław Wojnowski - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5: Grid#setupDataSource and GridDataSource
2009/6/24 Przemysław Wojnowski : > Hi! Hi! > Why Grid#setupDataSource() is calculating endIndex and not allowing for > GridDataSource to do it? Why GridDataSource#prepare method have > startIndex and endIndex parameters and not offset/limit pair? As offset = startIndex and limit = endIndex - startIndex + 1, I think their interchangeable for most scenarios. > I'm asking, because if GridDataSource could calculate endIndex (or use > limit instead) for itself, then there would be no need to call > getAvailableRows() before prepare(), which is a problem (at least IMHO). I guess getAvailableRows() is used for calculating the number of pages and then display the pager. > This would allow for single-call (those which receive number of > available rows, columns definitions, and columns values in one expensive > call) datasources to work. Please file a JIRA about this. Maybe we could use some special return value in GridDataSource.getAvailableRows() to indicate that it is not available yet and then call it again after GridDataSource.prepare(), thus solving your problem. -- Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
T5: Grid#setupDataSource and GridDataSource
Hi! Why Grid#setupDataSource() is calculating endIndex and not allowing for GridDataSource to do it? Why GridDataSource#prepare method have startIndex and endIndex parameters and not offset/limit pair? I'm asking, because if GridDataSource could calculate endIndex (or use limit instead) for itself, then there would be no need to call getAvailableRows() before prepare(), which is a problem (at least IMHO). Then Grid#setupDataSource() could look like this: void setupDataSource() { cachingSource = new CachingDataSource(source); int startIndex = (getCurrentPage()-1) * rowsPerPage; cachingSource.prepare(startIndex, startIndex+rowsPerPage, sortModel.getSortConstraints()); } This would allow for single-call (those which receive number of available rows, columns definitions, and columns values in one expensive call) datasources to work. Best regards, Przemysław Wojnowski - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org