+1 Perfect. Stephan
Am 23.04.2010 um 18:33 schrieb David Caruana: > Ok, well I have an implementation of getPage() without an explicit maxItems > parameter. I'll finish the tests and then checkin. > > We can then follow up with the next refactor which: > - renames PagingIterable to the chosen name :-) > - removes "maxItems" from the service calls > - adds maxItems to OperationContext > - adds a getPage(int maxItems) > > Dave > > > On 23 Apr 2010, at 17:21, Florent Guillaume wrote: > >> 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 > ---- Stephan Klevenz Fabrikstr. 45 69126 Heidelberg Tel.: +49 6221 879625 Fax.: +49 6221 339926
