> When you do ItemIterable.getPage() you get an iterable for the current > page. Is it the case that this iterable's iterator is intended to > iterate only over the page as it was defined at the time of its > creation, and that the underlying iterable (CollectionPageIterable) is > never supposed to stray beyond the bounds of this page? That would > make most sense to me as I don't see a use case where you'd want to > "escape" from the page. Only the main ItemIterable can give you new > pages. Can someone confirm that?
Yes, your understanding is correct. Dave On 7 Oct 2010, at 16:09, Florent Guillaume wrote: > Hi, > > I fixed most of this except the next() methods and the in-place skipTo(). > http://svn.apache.org/viewvc?view=revision&revision=1005481 > > Before fixing the next() I want to make sure I understand the intended > use of CollectionIterable vs CollectionPageIterable. > > When you do ItemIterable.getPage() you get an iterable for the current > page. Is it the case that this iterable's iterator is intended to > iterate only over the page as it was defined at the time of its > creation, and that the underlying iterable (CollectionPageIterable) is > never supposed to stray beyond the bounds of this page? That would > make most sense to me as I don't see a use case where you'd want to > "escape" from the page. Only the main ItemIterable can give you new > pages. Can someone confirm that? > > Florent > > > On Thu, Sep 9, 2010 at 2:54 PM, Florent Guillaume <[email protected]> wrote: >> Hi, >> >> A few things: >> >> 1. >> Currently our iterators (CollectionIterator, CollectionPageIterator) >> have a next() method that returns null at the end of the iteration. >> This is wrong and contrary to the Iterator contract, they should >> return NoSuchElementException in that case. >> Anyone opposed to fixing this? >> >> 2. >> Also I'd like to do small renamings like AbstractPageFetch -> >> AbstractPageFetcher and PageFetchResult -> FetchedPage or maybe even >> Page, and also rename getPage to getItems (or getList). >> >> 3. >> ItemIterable.skipTo returns a new iterable. I'm used to skipTo methods >> that just modify the iterable in place (for instance the JCR >> RangeIterator.skip or JCR2 EventJournal.skipTo or Lucene Spans.skipTo >> and TermDocs.skipTo), and in the use cases I've seen it's no use >> creating a new object. Is it ok to change this? >> >> 4. >> PageFetchResult has: >> public BigInteger getTotalItems() >> public Boolean getHasMoreItems() >> whereas ItemIterable has: >> long getTotalNumItems(); >> boolean getHasMoreItems(); >> I guess we have to keep Boolean and BigInteger to reflect the domain >> model here, but I'll sync the naming. >> >> Comments? >> >> Florent >> >> -- >> 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 >> > > > > -- > 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
