why not just fake the size to current page+1? that way you always have a "next" link and once you receive the current page you should know if you have more or not so you dont have to add the one on the last page....
-igor On Wed, Apr 11, 2012 at 6:59 PM, Dan Retzlaff <dretzl...@gmail.com> wrote: > Hi all. Time to start a thread of my own. :) > > Many of Wicket's powerful repeaters depend on IDataProvider. This interface > has a size() method which returns a non-null integer. This makes it easy to > determine the total number of pages in a pageable view, but IMO the > required computation and application complexity are not always called for. > In many cases, a pageable but open-ended data view is adequate. Have you > experienced this impedance mismatch yourselves? What was your solution? > > To elaborate on my experience: > > For SQL-based views, the application complexity comes from the need to > construct a count(*) query with exactly the same criteria as the subsequent > result query. In my experience, this pollutes DAO interfaces and > IDataProvider implementation non-trivially. We initially had separate > methods for counting and querying (same args), but eventually moved to a > single method that returns a <List,Integer>-tuple with both the results and > total size which our IDataProvider caches. This lets us do some Hibernate > trickery to introduce a MySQL SQL_CALC_FOUND_ROWS query hint, avoiding > separate count/results queries in most cases. It's still not simple, and > for large counts is still expensive. > > The situation is worse for non-SQL data stores which don't have a > fully-functional count(*) capability. We use Cassandra whose native "where > clause" support is limited, requiring significant client-side filtering. > Paging through an entire column (or CF) in this way is prohibitively > expensive, especially considering our users rarely even go to page 2. To > solve this, we've created a parallel set of view/paging classes that define > windows using previously discovered result keys instead of start indices > (tokens and column names in Cassandra). But having a full suite of > IUnsizedDataProvider-based classes smells. I love that Wicket devs have > solved some tough/tedious problems with DataViewBase and friends, and I > want to make use of them! > > Comments or suggestions? > > Cheers, > Dan --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
