This looks indeed like a bug to me. I opened a ticket for this:
https://issues.apache.org/jira/browse/WICKET-4568
-Tom
On 22.05.2012 at 21:10 Viliam Repan wrote:
> Hi,
>
> I've create sample mvn project, after build and deploy you can see
> sysouts like this:
>
> size() 100
> iterator() 0 10
> size() 100
> iterator() 0 10 <<<<after tomcat start and page loading
> size() 100
> size() 100
> iterator() 10 10 <<<<after click on next in navigation paging
> size() 100
> size() 100
> iterator() 20 10 <<<<after click on some page in navigation
> paging
>
> thank you for your help.
>
>
> vilo
>
> On 05/22/2012 06:15 PM, Thomas Götz wrote:
>> Could you please provide a quickstart that demonstrates your implementation?
>>
>> -Tom
>>
>>
>> On 22.05.2012 at 17:54 Viliam Repan wrote:
>>
>>> Hi,
>>>
>>> I probably found a bug in DataTable and PagingNavigator, or more likely
>>> I don't understand it correctly...
>>> I have page with one data table and two paging navigators in form, html
>>> part looks like this:
>>>
>>> <form wicket:id="mainForm">
>>>
>>> <div wicket:id="pTop"/>
>>>
>>> <div wicket:id="table"/>
>>>
>>> <div wicket:id="pBottom"/>
>>>
>>> </form>
>>>
>>>
>>> Java code - constructor:
>>>
>>> public PageTest() {
>>>
>>> Form mainForm = new Form("mainForm");
>>>
>>> add(mainForm);
>>>
>>> DataTable<UserType> table = new DataTable<UserType>("table",
>>> initColumns(),
>>>
>>> new ObjectDataProvider(PageTest.this, UserType.class), 10);
>>>
>>> table.setOutputMarkupId(true);
>>>
>>> mainForm.add(table);
>>>
>>> PagingNavigator pTop = new PagingNavigator("pTop", table);
>>>
>>> mainForm.add(pTop);
>>>
>>> PagingNavigator pBottom = new PagingNavigator("pBottom", table);
>>>
>>> mainForm.add(pBottom);
>>>
>>> }
>>>
>>>
>>> After first page load, I can see in logs:
>>>
>>> 2012-05-22 17:45:11,049 TRACE (c.e.m.w.c.d.ObjectDataProvider):
>>> begin::size()
>>> 2012-05-22 17:45:12,081 TRACE (c.e.m.w.c.d.ObjectDataProvider): end::size()
>>> 2012-05-22 17:45:12,081 TRACE (c.e.m.w.c.d.ObjectDataProvider):
>>> begin::iterator() from 0 count 10.
>>> 2012-05-22 17:45:12,546 TRACE (c.e.m.w.c.d.ObjectDataProvider):
>>> end::iterator()
>>>
>>> After click on next page, I see in logs:
>>> 2012-05-22 17:45:19,620 TRACE (c.e.m.w.c.d.ObjectDataProvider):
>>> begin::size()
>>> 2012-05-22 17:45:20,693 TRACE (c.e.m.w.c.d.ObjectDataProvider): end::size()
>>> 2012-05-22 17:45:20,696 TRACE (c.e.m.w.c.d.ObjectDataProvider):
>>> begin::size()
>>> 2012-05-22 17:45:21,722 TRACE (c.e.m.w.c.d.ObjectDataProvider): end::size()
>>> 2012-05-22 17:45:21,722 TRACE (c.e.m.w.c.d.ObjectDataProvider):
>>> begin::iterator() from 10 count 10.
>>> 2012-05-22 17:45:22,164 TRACE (c.e.m.w.c.d.ObjectDataProvider):
>>> end::iterator()
>>>
>>> size() method in data provider is called twice, that's probably a bug. I
>>> have many objects in db (up to 500k),
>>> so it's a 1s-2s difference in response time. I'm suspecting that it's
>>> caused by AbstractPageableView.getCurrentPage(),
>>> because there is a check which calls getPageCount() which calls
>>> getItemCount(). There is some caching mechanism for count,
>>> but it's not working in this case...
>>>
>>> Can somebody help please, any ideas?
>>>
>>>
>>> Vilo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
> <datatable-sample.zip>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
