wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Vaynberg <igor.vaynb...@gmail.com>
Subject Re: AbstractPageableView cachedItemCount
Date Thu, 16 Feb 2012 00:33:54 GMT
so when should it be discarded?

-igor

On Wed, Feb 15, 2012 at 4:25 PM, Jonathan Tougas <jtougas@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 <dretzlaff@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 <jtougas@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 <dretzlaff@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 <jtougas@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
>> > > >
>> > >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Mime
View raw message