Hi, I would propose SkippableIterable for the new name. It describes what this does, "Item" is a bit meaningless.
Regarding simplified APIs I like them. Putting a default page size in the OperationContext is good. When using the API, I'd like it to be possible for a client to not care at all about page sizes, and let it assume that "the system" will choose appropriate defaults. Florent On Fri, Apr 23, 2010 at 4:58 PM, David Caruana <[email protected]> wrote: > With the MIX option, I assume you also propose to remove the "maxItems" > parameter from service calls. > >> PagingIterable<QueryResult>) results = session.query("select ...", false); > >> for (QueryResult result : results) { ... } >> for (QueryResult result : results.skipTo(100)) { ... } >> for (QueryResult result : results.getPage()) { ... } > > >> for (QueryResult result : results.getPage(10)) { ... } >> for (QueryResult result : results.skipTo(100).getPage()) { ... } > >> for (QueryResult result : results.skipTo(100).getPage(10)) { ... } > > > I'm ok with this, as long as there is some way of defining a session or > OperationContext default for maxItems, for the case where a client iterates > through all items in the CMIS collection. > > Any other proposals or thoughts from anyone? > > Dave > > On 23 Apr 2010, at 14:12, Klevenz, Stephan wrote: > >> Hi Dave, >> >> Good coding example. Between our two proposals is only a little difference >> and also a mix is possible: >> >> YOU: PagingIterable<QueryResult>) results = session.query("select ...", >> false, 10); >> ME: PagingIterable<QueryResult>) results = session.query("select ...", >> false); >> >> YOU: for (QueryResult result : results.getPage()) { ... } >> ME: for (QueryResult result : results.skipTo(0, 10)) { ... } >> MIX: for (QueryResult result : results.getPage(10)) { ... } >> >> YOU: for (QueryResult result : results.skipTo(100).getPage()) { ... } >> ME: for (QueryResult result : results.skipTo(100, 10)) { ... } >> MIX: for (QueryResult result : results.skipTo(100).getPage(10)) { ... } >> >> From functional point of view it's all the same. Free choice :-) I'd like >> the MIX. >> >> Regards, >> Stephan >> >> -----Original Message----- >> From: David Caruana [mailto:[email protected]] >> Sent: Freitag, 23. April 2010 14:35 >> To: [email protected] >> Subject: Re: PagingIterable >> >> 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 >>> >>> >>> >> > > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
