Just got a bit of time to work on the dataview, it is now itself pageable. > That's a very good idea. I also do not like PageableDataView > with the unsupported methods.
Well, some of the methods have to stay locked since they really don't make sense withing the paging context. However, it might be a good idea to simply get rid of them since paging can be used to achieve similar results. Of course paging is not as flexible in certain situations as using setStartIndex() and setViewSize() but the question is do we want to trade that flexibility for clarity? > I was just concerned about > memory. Lazy-creation of a PageableSupport solves that. I > think you mean when not enabled > getPageCount() either returns 1 or 0, getCurrentPage() > returns pageCount-1 and setCurrentPage() does nothing. Cool > idea, would be completly transparent and (nearly) no > additional memory. Yes the support delegate is lazily created. Setcurrentpage() throws illegalstateexception if paging is disabled. > Maybe you could than also add a protected method > populateItems(int start, int count) which does the DataItem > population and gets called from internalOnBeginRequest(). So > GridDataView could (esaly) extend the new DataView. I concentrated just on paging right now, I will do this next when I get a bit more time. -Igor ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
