You can just take AbstractPageableView, IDataSource and IGridSortState from the code. It should do exactly what you want and It shouldn't have any dependencies on the rest of grids.
-Matej On Wed, Nov 26, 2008 at 5:39 PM, Wayne Pope <[EMAIL PROTECTED]> wrote: > Hi Matej, > >>The idea is always to load one row more than required on page which >>tells the grid if there will be a next page or not. > > Great idea. I looked at the code and I think I'll do my own (simplied > version) of your refreashingpage. I believe thats what we really want here, > as we don't care about telling the user the total amount of rows. > > Thanks everyone for your comments and help > Wayne > > On Wed, Nov 26, 2008 at 5:21 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > >> Hi Wayne, >> >> if you feel brave enough you can take a look at inmethod grid >> components (available in wicket stuff svn - >> http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff in trunk >> and 1.3 branch). The grid contains AbstractPageableView that can >> perform paging without having to know the number of rows upfront. >> >> The idea is always to load one row more than required on page which >> tells the grid if there will be a next page or not. >> >> -Matej >> >> On Wed, Nov 26, 2008 at 5:15 PM, Wayne Pope >> <[EMAIL PROTECTED]> wrote: >> > Hi James, >> > >> > its not killing anything at the moment, I just don't like the idea of >> > hitting the database with due cause. >> > However I thinking about this some more I believe perhaps I should not >> use >> > DataViews full stop - but RefreshingView instead?. Essentially I have in >> > several places a large data set. I'm only interested in displaying say >> the >> > first 10 rows. Then the user can click on "load next 10" and thus display >> > the next 'page' of results. They then have a choice of loading the next >> 10 >> > or the previous 10, etc. Perhaps DataView is not really suited to this >> type >> > of behaviour? more used where you want to see the number of pages a >> search >> > result finds for example? If we're at the edge condition that there are >> > exactly 20 results, when asking for the next 10, we simply disply the >> > message 'no more results'. >> > >> > >> >>We just issue a count(*) query first to get the count >> > Yes so this will be called every time the page is rendered no unless you >> > cache as you stated, but you run the risk changing dataset? >> > >> > thanks >> > Wayne >> > >> > On Wed, Nov 26, 2008 at 5:05 PM, James Carman < >> [EMAIL PROTECTED]>wrote: >> > >> >> We just issue a count(*) query first to get the count. Then, we use >> >> individual queries to get each page's data. If you feel confident >> enough >> >> that the count won't change (or you don't really care if it does), you >> can >> >> cache the value returned from it the count query (I don't know how often >> >> that gets called, really). If calling the queries to get the individual >> >> page's data is killing your database, then you're doing something wrong, >> >> IMHO. >> >> >> >> On Wed, Nov 26, 2008 at 10:32 AM, Wayne Pope < >> >> [EMAIL PROTECTED]> wrote: >> >> >> >> > Hi, >> >> > >> >> > thanks for the replies. >> >> > >> >> > Micheal O/Hoover - I still don't see how this works as you don't have >> the >> >> > limit and offset (that is used in Iterator). How do you know how many >> >> rows >> >> > to load in your size() method? >> >> > >> >> > Michael S - thanks for the link - it it appears I must completely >> rewrite >> >> > the whole pagable/provider code (not looked at the code) to get this >> to >> >> > work? >> >> > >> >> > I'm sure I must be missing something still, as I can't beleive that we >> >> need >> >> > to either a) load the whole data set b) call count on the Db , then >> load >> >> in >> >> > the iterator mehod. Thats going to kill the database in prod (or >> really >> >> not >> >> > help.) >> >> > >> >> > On Wed, Nov 26, 2008 at 3:58 PM, Michael Sparer < >> [EMAIL PROTECTED] >> >> > >wrote: >> >> > >> >> > > >> >> > > have a look at https://issues.apache.org/jira/browse/WICKET-1784 >> >> > > >> >> > > >> >> > > Wayne Pope-2 wrote: >> >> > > > >> >> > > > Ok, >> >> > > > >> >> > > > I was just having a bit of code clean up and I realized that in >> our >> >> > > > IDataProviders we are loading all rows for a given dataset. >> >> > > > So looking at the iterator method I see we can limit the result >> (and >> >> > the >> >> > > > offset). Great I thought - however I see that that the size() >> method >> >> is >> >> > > > called as part of the getViewSize() in the AbstractPageableView. >> Thus >> >> I >> >> > > > need >> >> > > > to call the database here to figure out the size. >> >> > > > >> >> > > > Am I doing sonething wrong or have I got to hit the database twice >> >> for >> >> > > > each >> >> > > > DataProvider render. >> >> > > > >> >> > > > Obvously I don't want to hard code a size. Is there any other way >> ? >> >> > > > >> >> > > > Thanks >> >> > > > Wayne >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > > ----- >> >> > > Michael Sparer >> >> > > http://talk-on-tech.blogspot.com >> >> > > -- >> >> > > View this message in context: >> >> > > >> >> > >> >> >> http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20702476.html >> >> > > Sent from the Wicket - User mailing list archive at Nabble.com. >> >> > > >> >> > > >> >> > > >> --------------------------------------------------------------------- >> >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > >> >> > > >> >> > >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
