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]
