[WICKET-1784] Enhance IDataProvider to support applications using the Transfer Object J2EE pattern

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.3.3, 1.4-M3
• Fix Version/s: 1.4-RC2
• Component/s: wicket
• Environment: Wicket 1.3.3 and 1.4-M3
• Assignee: Igor Vaynberg
• Reporter: R. Goodwin
• Created: 09/Aug/08 18:27
• Updated: 27/Nov/08 17:36
• Resolved: 27/Nov/08 17:36

Description

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/[e-mail]/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.