[jira] Commented: (WICKET-1784) Enhance IDataProvider to support applications using the Transfer Object J2EE pattern

["R. Goodwin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627402#action_12627402 ] 

R. Goodwin commented on WICKET-1784:
------------------------------------

Looks like PagingNavigationLink is calling getPageNumber to protect against possible data deletions.
Clever simple code, but the pain is felt for me at the data provider end.

public void onClick()
{
	pageable.setCurrentPage(getPageNumber());
}

Looks like PagingNavigationIncrementLink is doing other stuff with page count.

Can't see a quick win to resolve this cleanly. Would probably have to re-write these Link classes, which effectively means having to re-write all the paging comps :(

Would add similar 2-phase behaviour as I did to SinglePassDataView, where 1) request is made for a page, then 2) check made afterwards to see if that's the one that was loaded and self-correct if it wasn't.

Think I'll call this the 'ask nicely before taking' approach.

> 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/users@wicket.apache.org/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.