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: [email protected] > 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: [email protected] > > 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: [email protected] > > > 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: [email protected] > > > 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: [email protected] > > > > 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] > >
