[
https://issues.apache.org/jira/browse/WICKET-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627292#action_12627292
]
R. Goodwin commented on WICKET-1784:
------------------------------------
Just saw something you wrote Dec 10 2007:
"we need to rethink how the whole size() thing is dealt with"
http://www.nabble.com/enclosures-and-dataview-td14258879.html#a14258879
Well, a re-think could include giving the potential error condition underlying
the dependency on size() a name:
'Offset out of bounds'
Having now named the devilish scenario, adding code explicitly to deal with it
head on seems more natural rather than a hack.
My example app demonstrates that it's relatively easy to deal with offset out
of bounds.
Forget original (and complicated) suggestion of having different strategies for
handling it.
Re-querying to the last known 'good' page suffices,
which will back up all the way to page 1 if necessary.
Did you try my runnable demo, and see how it copes when items are deleted
between paging requests?
Come on, give it another chance :)
There is potentially a good contribution to Wicket here.
I think you could change DataView internally without having to add nonsense
like .onWantsPopulating() to the provider interface. Just changing the
interaction so that iterator() is always called before size() may be enough to
work. And of course you'd have to cache the first call to size() in the
constructor to keep the paging comps happy.
> Enhance IDataProvider to support applications using the Transfer Object J2EE
> pattern
> ------------------------------------------------------------------------------------
>
> Key: WICKET-1784
> URL: https://issues.apache.org/jira/browse/WICKET-1784
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.3, 1.4-M3
> Environment: Wicket 1.3.3 and 1.4-M3
> Reporter: R. Goodwin
> Assignee: Igor Vaynberg
> Attachments: wicket-paging-experiment.zip
>
>
> In some environments searches are performed in 'single call' fashion, using a
> transfer object.
> E.g. two queries performed by the data services tier before returning
> combined results to the UI tier:
> i. Query for paged search results
> ii. Query for a 'count' value representing total possible results
> The contract between DataView and IDataProvider does not support a 'single
> call' environment as the give/take relationship between these classes is
> biased towards DataView.
> DataView expects IDataProvider to provide it's size before providing
> IDataProvider with its offset and count.
> * DataView may have good reasons for needing size before it can provide
> offset/count.
> * But IDataProvider has equally good reasons for needing offset/count before
> it can provide size.
> The circular dependency:
> 1. DataView calls IDataProvider.size()
> 2. IDataProvider cannot return size as it cannot start a query until it
> receives offset/count from DataView
> 3. These it does not receive until DataView calls IDataProvider.iterator()
> later on
> Others who experienced this problem (with CODE examples):
> * http://www.nabble.com/IDataProvider-and-Hibernate-Search-td15546101.html
> * http://www.mail-archive.com/[EMAIL PROTECTED]/msg14266.html
> ---
> The suggested solution of caching the combined search results and count value
> does not work if the search cannot begin until offset and count are
> available. And writing a custom DataView is not feasible either time wise as
> I understand that it cannot be done without needing to write a number of
> other classes too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
