no cache the size. We first have to have the size to be able to give you the offset and count params. And depending of the type of data or the database you use you could also already query the data (in the size() call) But i know that is not always the best thing to do.
But do you want an extra 2 params also in the size() call? What would be the offset and what would be the max length? The problem is that both of those depends on the size call..... So the offset is calculated with the size param as is the count.. So if we try to guess those 2 params for the size() call then those 2 params dont have to be the same for the iterator call... johan On Thu, Mar 27, 2008 at 1:01 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > Also, you mention that all that is needed is to cache it (I assume you are > referring to the actual data) in the data provider. How can that be done > when the size is being called when there is no way to get the current offset > that is needed to get the data in the first place? > > -----Original Message----- > From: Hoover, William [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2008 7:55 AM > To: users@wicket.apache.org > Subject: RE: DataView size() iterator() call order issue > > > The difference is that in the deletion scenario the state of the data has > changed. In the pagination scenario the state of the data has not changed. > Why is that so difficult to differentiate? > > -----Original Message----- > From: Johan Compagner [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2008 7:49 AM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > > and how do we know the difference? > > You as a developer know it, we dont know it as a framework, just cache it > in > your dataprovider or wrap in in a caching data provider. Why is that so > difficult > > johan > > > On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]> > wrote: > > > That makes perfect sense in the scenario where rows are deleted, but it > > doesn't make sense when all that is being done is clicking the next > button > > for a PagingNavigator. Why would do we need two calls to the size method > in > > that scenario? > > > > -----Original Message----- > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 26, 2008 3:27 PM > > To: users@wicket.apache.org > > Subject: Re: DataView size() iterator() call order issue > > > > > > On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <[EMAIL PROTECTED]> > > wrote: > > > 2) Although AbstractPageableView does ensure the cached item count is > > used before calling the data provider size() in getRowCount(), the > cached > > item count is "cleared" in onBeforeRender() before the call is made to > > getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() > when > > getting the item models in getItemModels(); This causes an unnecessary > > duplicate call to the data providers size() method when paginating. > > > > it is not unnecessary > > > > suppose you have a dataview with overridden isvisible() { return > > getitemcount()>0; } > > inside this dataview you have a delete link > > > > suppose dataview loads and has 1 item. > > user clicks delete > > wicket checks the link is indeed visible - which results it the size() > > call which in turn caches the result > > onclick() handler is invoked > > row is removed > > onbeforerender is called > > dataview is rendered > > > > in this case dataview is rendered because getitemcount() has been > > cached before onclick() has been executed, so the cached count is 1 > > when in reality there are now 0 items. that is why onbeforerender() > > clears the cache, and why sometimes you will get two size() calls. > > > > -igor > > > > --------------------------------------------------------------------- > > 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
