Wayne,

 
http://donteattoomuch.blogspot.com/2008/04/partial-ajax-update-capable-list-view.html
This  may be interesting too.

Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk 



Wayne Pope-2 wrote:
> 
> Thanks Matej,
> 
> I just noticed org.apache.wicket.markup.repeater.AbstractPageableView<T>
> which seems what I'm ofter - I'll have a look and both and get something
> working.
> 
> 
> On Wed, Nov 26, 2008 at 5:57 PM, Matej Knopp <[EMAIL PROTECTED]>
> wrote:
> 
>> 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]
>>
>>
> 
> 
http://donteattoomuch.blogspot.com/2008/04/partial-ajax-update-capable-list-view.html
http://donteattoomuch.blogspot.com/2008/04/partial-ajax-update-capable-list-view.html
 
-- 
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-tp20701684p20706800.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]

Reply via email to