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]
