Can you post code for an example data provider that would KNOW how to cache the size?
-----Original Message----- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 10:47 AM To: users@wicket.apache.org Subject: Re: DataView size() iterator() call order issue no you as a developer KNOW that it can cache it Cache it if you can dont if you cant On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > Okay, two issues... (1) combined call for size/data (2) multiple calls to > size() when paginating > > I will avoid confusion by addressing only the multiple calls to size() for > now. > > If only the size was to be cached, as you suggested, how would the data > provider know when to clear it? The data provider is statefull and maintains > the size across requests and there is no "onBeforeRender" in a data provider > like there is in AbstractPageableView. So, the size will never be cleared > when paginating from one page to the next. Even if we were able to cache the > size we would be maintaining the same data in two different locations- in > the AbstractPageableView -> cachedItemCount and in the data provider. > > -----Original Message----- > From: Johan Compagner [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2008 8:12 AM > To: users@wicket.apache.org > Subject: Re: DataView size() iterator() call order issue > > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
