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 <jtou...@gmail.com> 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 when a request comes in to handle > a click. > > On Wed, Feb 15, 2012 at 5:19 PM, Dan Retzlaff <dretzl...@gmail.com> 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 <jtou...@gmail.com> > > 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 <dretzl...@gmail.com> > > 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 <jtou...@gmail.com> > > > > 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 > > > > > > > > > > > > > > >
