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 <[email protected]> wrote: > 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 at 1:37 PM, Jonathan Tougas <[email protected]> > wrote: > > > 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 clear I am discussing multiple size() calls in one request. It > > happens when clicking on the navigation links: size() is called first as > > part of the verifying if the link is enabled (as described above), then > the > > cached value is discarded just before rendering (in onBeforeRender()). > Then > > size() is called again as part of the rendering, and again cached. The > > cached value is again discarded at the end of the request in onDetach(). > > What I'm saying is the the first size() shouldn't occur because the page > > count should be cached from the previous rendering (it shouldn't be > cleared > > in onDetach() nor readObject()). > > > > On Wed, Feb 15, 2012 at 1:09 PM, Dan Retzlaff <[email protected]> > wrote: > > > > > 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 for it. > > > > > > > > > How can you receive a click event for a link that was not visible? > > > Invisible components aren't rendered. > > > > > > That JIRA discusses multiple size() calls in a single request. You're > > > discussing multiple size() calls with multiple requests. Right? > > > > > > Dan > > > > > > On Wed, Feb 15, 2012 at 9:31 AM, Jonathan Tougas <[email protected]> > > > wrote: > > > > > > > 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 basis for the paging navigator's > > isVisible(), > > > so > > > > far so good. The issue is that the count is discarded in onDetach() > (as > > > > well as readObject()). 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 for it. If it's not > > kept, a > > > > new query to the model will be made, which might return a different > > > result > > > > - consequences ensue. The critical part of that is we are checking if > > the > > > > link *was* visible, not if it *is* visible. > > > > > > > > I think the only time it should be discarded is in the > onBeforeRender() > > > > event. This is when we are actually interested in going back to the > > model > > > > to see if the value has changed. So to me this is indeed a bug. I > don't > > > > mind patching something up myself, or reopening the ticket...but I > > would > > > > like a confirmation that I'm not way out in left field ;) > > > > > > > > Cheers! > > > > Jonathan Tougas > > > > > > > > > >
