Perfect! detach was the missing piece of the puzzle, thank you! The only issue remaining is the capability to combine the size/iterator call to prevent duplicate DAO calls.
-----Original Message----- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Thursday, March 27, 2008 12:02 PM To: users@wicket.apache.org Subject: Re: DataView size() iterator() call order issue forgot: public class MYSizeCachingDataProvider ... { public void detach() { size = null; resultset = null; } } On 3/27/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > public class MySizeCachingDataProvider implements IDataProvider { > private Integer size = null; > private List<Foo> resultset = null; > public int getSize() { > if(size == null ) { > performExpensiveQuery(); > } > return size; > } > public Iterator iterator() { > if(resultset == null ) { > performExpensiveQuery(); > } > return resultset; > } > private void performExpensiveQuery() { > size = count(); > resultset = query(); > > } > } > > On 3/27/08, Hoover, William <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.2 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2 > -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.2 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2 --------------------------------------------------------------------- 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]
