I apologize that I missed the detach() portion of your email :o) I don't want to beat the issue on needing size before offset/count and waste anymore of anyone's time. In a legacy application we have I already accomplished this. So, I will just use some customization to the wicket components and incorporate the code from the legacy JSF application. Thanks for your time!
-----Original Message----- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2008 8:59 AM To: [email protected] Subject: Re: DataView size() iterator() call order issue i already mentioned detach() in my fist reply to this thread 2 days ago... and as i said before both variables that go into the iterator() are depending on the size call so the size() call really needs to happen first or we have to just guess those 2 variables completely johan On Fri, Mar 28, 2008 at 1:23 PM, Hoover, William <[EMAIL PROTECTED]> wrote: > 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: [email protected] > 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: [email protected] > > > 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: [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] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
