I'm only interested in caching it for the current request so there isn't multiple calls to size within the same request. The same way AbstractPageableView is caching it and clearing it in "onBeforeRender". The only problem is that:
1) I do not have access to the cached size stored in AbstractPageableView -> cachedItemCount from within the data provider 2) The cached size in AbstractPageableView -> cachedItemCount is "cleared" in onBeforeRender() before the call is made to getViewOffset() -> getCurrentPage() -> getPageCount() -> getRowCount() when getting the item models in getItemModels(); This causes a second call to the data providers size() method when paginating. In other words, the AbstractPageableView -> cachedItemCount is not working properly when a link for the PagingNavigator is clicked- causing 2 calls to the size() method within the same request (w/o deletions ;o). -----Original Message----- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 11:36 AM To: users@wicket.apache.org Subject: Re: DataView size() iterator() call order issue If you are iterating over a list that can be changed by all kinds of different users Then you cant really cache it If you are iterating over a list that is pretty stable for the current users or the user itself only alters that list (insert/delete) Then you can cache it easily Just call detach (that clears the size cache) when you have an action that deletes or inserts a new items so that you know the size is changed. johan On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
