[
https://issues.apache.org/jira/browse/WICKET-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12831244#action_12831244
]
bernard commented on WICKET-2532:
---------------------------------
Thanks very much.
Currently there is no sulution at all, and I would like to be humble with
respect to what kind of possible solution of this problem.
Removing "navigate to last page" would definitely solve it but you might find
better solutions, too.
What about letting the framework call iterator.hasNext() one more time even
after the size() number is exhausted, pushing the dataprovider to fetch a new
buffer and increase size? This would work only if Wicket would adjust to the
new size, too.
If there was a parameter in the size() call, or callback that the DataProvider
could call to find the requested page position that would be great.
Unfortunately this info must be available, and I found that
a) it isn't at the time of the first size() call which is the subject of the bug
b) the call I used to get the requested position called back into size() so I
ended up with infinite recursion.
(This jira text box is one character wide on my Firefox 3.6, I can't see while
I am typing)
> Pageable Views call IDataProvider.size() more than once
> -------------------------------------------------------
>
> Key: WICKET-2532
> URL: https://issues.apache.org/jira/browse/WICKET-2532
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.1
> Environment: All
> Reporter: bernard
> Fix For: 1.5-M1
>
> Attachments: ContactDataProviderTest.java, PagingPage.java
>
>
> IDataProvider.size() is typically an expensive database operation. It is
> called twice in typical Pageable View scenarios although Wicket makes
> attempts to avoid that. In addition, the first call is premature from the
> application perspective because it is made while the the requested page
> position is not yet known.
> How to reproduce:
> Drop in the attached files into the Wicket examples application and run:
> repeaters|Paging DataView Example - builds on previous to demonstrate paging
> and page navigation
> Otherwise I am running against a wall with IDataProvider.size() and
> AbstractPageableVew because I can't find any way to get the page position at
> the same time when IDataProvider.size() is called. Support of paging of
> results of unknows size is impossible without this information. Please refer
> to Google search results paging - that is the kind of paging we need.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
