[
https://issues.apache.org/jira/browse/WICKET-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622145#action_12622145
]
R. Goodwin commented on WICKET-1784:
------------------------------------
Yes, on the rare occasion where offset exceeds the total count, some kind of
additional behaviour needs performing to self-correct.
Perhaps having something like this in the topmost superclass that deals with
paging like:
enum UnexpectedResultsAction {
REDIRECT_TO_PREVIOUS, // go back to previous page, may still
fail though
REDIRECT_TO_LAST, // you'd have an updated size, so
navigate to last possible page
REDIRECT_TO_PAGE // go somewhere else to provide
custom feedback message
}
setBehaviourOnUnexpectedResults(UnexpectedResultsAction action);
I understand Its not very nice to pollute your framework with code for dealing
with edge cases.
But I think you need to encode into Wicket the concept and means of resolving
the mismatch between 'expected' results and 'actual' results. Currently, you
circumvent this mismatch problem at the expense of restricting how and when
IDataProvider is able to get its data.
---
The Transfer Object pattern is used in unexpected ways.
A Lucene query returns both results and count in one query.
I don't think you'll be able to convince teams using Lucene that they need to
switch to making separate calls instead. And as said, caching results doesn't
work as offset and count aren't known at the time search is executed.
---
Personally I'd find this interface more flexible:
interface IDataProvider {
public void onRequestsData(int offset, int count);
public long size();
public Iterator iterator();
// other methods ...
}
* onRequestsData() would always be called first and is the 'heavy' call
* Subsequent calls to size() and iterator() would be 'light' calls
* size() could be called any number of times in a single request without
needing to cache the value higher up the chain, as the data retrieval stage
would already have completed.
This fits with the expected behaviour of a size() method call as well. Can't
think of any class I ever used (e.g. List, Map) that performs a heavy operation
on invocation of its size() method. Have always felt free to call it one or
more times without concern for performance.
Don't have any ideas about backwards compatibility issues with existing Wicket
apps though.
> 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
>
> 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.
