On Thu, Apr 12, 2012 at 9:12 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > On Thu, Apr 12, 2012 at 4:59 AM, 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? > > Wicketstuff InMethod Grid supports this use case. > One of its examples shows it. > I'll deploy the examples at wicket-library.com soon.
http://www.wicket-library.com/inmethod-grid/data-grid/unknown-count > >> >> 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 > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
