Hi Stephan,
I'm currently experimenting with the new PagingIterable in the context of a
simple query web page. So, have some thoughts on your discussion points.
On 23 Apr 2010, at 13:06, Klevenz, Stephan wrote:
> Hi,
>
> One follow up task after F2F was to finish the implementation of the
> PagingIterable interface. This is finished now.
>
> In the client impl module you'll find a unit test testing the default
> implementation. In FIT module all APIs returning an Iterable are also covered
> by basic unit tests.
>
> I have open points for discussion:
>
> a) Naming: Actually the interface behaves like an interval. Paging is
> more or less an optimization of the implementation not to read all elements
> in one call. My naming proposal would be "ItemIterable" for CmisObjects,
> QueryResults, Events, ObjectTypes ...
+1
> b) Paging Parameter or itemsPerPage: Used in all API returning an
> Iteable e.g.
>
> PagingIterable<Document> getCheckedOutDocs(int itemsPerPage);
>
> As said this is more an optimization rather than a real page which should
> have a begin and an end. I propose to eliminate this parameter in API and
> assign it to the session (or OperationContext) as a global optimization
> parameter.
If the parameter is removed, I'd like to see it at least available in
OperationContext.
> c) SkipCount: Because of totalNumItems is an optional value (s. CMIS
> 2.2.1.1) an application can not necessarily calculate the maximum of
> skipCount parameter. Current implementation runs out of bound if skipCount >
> totalNumItems. This is maybe a bug and it would be better implementation
> accepts a high skipCount. In that case the Iterable returns not more items.
Seems like a bug. +1 to return false for hasNext() in this case.
> d) skipTo(pos): I propose another (optional) parameter maxItems for this
> method. Currently the Iterable returns all elements.
I'm experimenting with an additional getPage() method on PagingIterable. This
returns an Iterable for the current page of items only. This is similar to your
proposal except it inherits the maxItems from the provided page fetcher.
So, if you execute a query as such:
PagingIterable<QueryResult>) results = session.query("select ...", false, 10);
You can iterate through all rows as such:
for (QueryResult result : results) { ... }
You can iterate through all rows from specified starting position:
for (QueryResult result : results.skipTo(100)) { ... }
You can iterate through a page of rows:
for (QueryResult result : results.getPage()) { ... }
for (QueryResult result : results.skipTo(100).getPage()) { ... }
e) I'd also like to propose the additional method hasMoreItems() on
PagingIterable which allows access to the hasMoreItems output parameter of CMIS
services which return collections.
> Let me know what do you think.
>
> Regards,
> Stephan
>
>
>
