Re: AbstractPageableView cachedItemCount

2012-02-17 Thread Jonathan Tougas
I see your point, the order the components are rendered is important. I didn't have any trouble getting this to work though: I have a UserListPage, which has a SizeLabel (whose getModel() = datatable.getgetItemCount()), and a UserDataTable. The UserListPage listens for ajax events to add the SizeL

Re: AbstractPageableView cachedItemCount

2012-02-16 Thread Igor Vaynberg
suppose you have a label before the data table that shows how many items are in the table. it uses datatable.getitemcount() to do this. onbeforerender() will be called on the label before it is on the datatable so it now uses the stale item count and is out of sync with the datatable. -igor On T

Re: AbstractPageableView cachedItemCount

2012-02-16 Thread Jonathan Tougas
It should be discarded only before rendering. I figured out a way to accomplish this by extending the DataTable class and creating a wrapper for the data provider with a cache of it's own, which bypasses the AbstractPageableView's size cache. This one is cleared by the extension of DataTable befo

Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Igor Vaynberg
so when should it be discarded? -igor On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas wrote: > The cachedItemCount calculated in onBeforeRender should not be discarded at > the end of a request (so the clear in onDetach and readObject shouldn't be > there). This way it would still be around whe

Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Dan Retzlaff
I understand your suggestion. But if the page to which the link refers no longer exists based on the new data content, isn't it a bad idea to go there? I feel like I'm drawing this out. Sorry for that. :) On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas wrote: > The cachedItemCount calculated i

Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Jonathan Tougas
The cachedItemCount calculated in onBeforeRender should not be discarded at the end of a request (so the clear in onDetach and readObject shouldn't be there). This way it would still be around when a request comes in to handle a click. On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff wrote: > Thank

Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Dan Retzlaff
Thanks for the clarification. I see your point now: if records are deleted from the database, the navigation click is ignored an the page is simply re-rendered. But if the data content has changed such that the navigation no longer makes sense, what behavior would you prefer? On Wed, Feb 15, 2012

Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Jonathan Tougas
The PagingNavigationIncrementLink's linksTo(Page), which calls isLast() which calls pageable getPageCount() which ends up calling size() eventually. This is called during Component.canCallListenerInterface (*you're right it's not isVisible*) to verify if the link can indeed be clicked. And to be c

Re: AbstractPageableView cachedItemCount

2012-02-15 Thread Dan Retzlaff
Hi, Jonathan. Which component are you referring to? I don't see isVisible() overrides in PagingNavigator or its helpers. > It's state and as such should not be discarded when > the request is finished, it's still needed for things like checking if a > link was indeed visible when a click comes in

AbstractPageableView cachedItemCount

2012-02-15 Thread Jonathan Tougas
I noticed two count queries go by when using the DataTable component. so I searched and dug up this jira issue https://issues.apache.org/jira/browse/WICKET-1766 which is a "won't fix". Igor states that two queries are required each request, but I see this differently: The count is a used as the b