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
