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 before rendering like I'm suggesting:
public class SuperTable<T> extends DataTable<T> {
private SuperDataProviderWrapper<T> dataProviderWrapper;
public SuperTable( String id, List<IColumn<T>> columns,
SuperDataProviderWrapper<T> dataProviderWrapper, int rowsPerPage ) {
super( id, columns, dataProviderWrapper, rowsPerPage );
this.dataProviderWrapper = dataProviderWrapper;
setOutputMarkupId( true );
setVersioned( false );
addTopToolbar( new AjaxNavigationToolbar( this ) );
addTopToolbar( new AjaxFallbackHeadersToolbar( this, dataProviderWrapper )
);
addBottomToolbar( new NoRecordsToolbar( this ) );
}
@Override
protected Item<T> newRowItem( final String id, final int index, final
IModel<T> model ) {
return new OddEvenItem<T>( id, index, model );
}
@Override
protected void onBeforeRender() {
// reset size before rendering!
dataProviderWrapper.resetSize();
super.onBeforeRender();
}
}
public class SuperDataProviderWrapper<T> implements
ISortableDataProvider<T> {
private ISortableDataProvider<T> delegate;
private int size;
public SuperDataProviderWrapper( ISortableDataProvider<T> delegate ) {
this.delegate = delegate;
resetSize();
}
@Override
public int size() {
if( size == -1 ) {
size = delegate.size();
}
return size;
}
public void resetSize() {
size = -1;
}
/*snip delegations...*/
}
End result is one call to count when the ajax links are clicked instead of
two.
On Wed, Feb 15, 2012 at 7:33 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> so when should it be discarded?
>
> -igor
>
> 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
> >> > > >
> >> > >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
