[
https://issues.apache.org/jira/browse/WICKET-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626803#action_12626803
]
Igor Vaynberg commented on WICKET-1784:
---------------------------------------
> Well, everything's possible to implement externally isn't it.
no, not always. a good framework always has a way out...looks like you found one
> But was I saying it was so easy ... for the long term?
> Subclassing RefreshingView means losing (or re-writing) the functionality in
> AbstractPageableView,
> including all that stuff with versioning and the Change object.
you are doing paging in a significantly different way, so i dont think there is
anything wrong with having to rewrite paging-related components. basically you
are forcing the paging navigator to depend on the dataprovider instead of a
simple size() call which ipageable provide and not just the dataview
implements... can you rewrite them to work the way that you want without
breaking api?
> Bit too much detail for someone just starting out with Wicket isn't it?
this is not a trivial thing so there is nothing wrong with having to know more
then trivial things about the framework you are using. you seemed to have done
just fine...
> And are you confident that data retrieval by DTO is a rare use case?
wicket has been around for 3+ years and this is the second time this has come
up. im pretty confident 100% of wicket apps out there use paging repeaters...so
yeah...im sure :)
> It's easy to write off J2EE patterns as out of date.
this has nothing to do with this pattern being out of date.
> But the Transfer Object pattern resurfaces in mysterious ways. For example,
> how could one integrate Wicket with the
> 3-tier Command pattern for data access suggested by Bauer and King in Java
> Persistence with Hibernate? pp. 718-724.
> Their solution also behaves like a DTO-over-the-wire pattern too.
even 3-tier systems usually have a call to retrieve just the size of the
dataset, at least all the ones ive worked with did. if you are concerned with
performance you can cache the size on the clientside for x minutes.
> You know, the really great frameworks like Hibernate and Spring always
> provide helper classes for those tricky situations.
> Having to extend a framework class midway through the class hierarchy is
> really a last resort. :)
there is absolutely nothing wrong with having to extend a framework class
midway through the hiearachy. hieararchy is about layering functionality, you
pick the subclass that offers the most that you can use and extend it.
unfortunately for you, paging is very foundamental and is thus near the top of
the hierarchy, so you do get to miss out on the bottom pieces.
> Have you seen:
> http://www.nabble.com/Paging-query-relating-to-IDataProvider-and-Lucene-search-td19083164.html
what about it? that thread didnt get much traffic.
> 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.
