Hi, sorry for joining the game a bit late ... At the moment it's not clear to me, why we actually want to extend the API with this functionality; while I totally understand the value and beauty of streams, I wonder if the usecase "traverse the whole subtree" happens really that often that it qualifies for an extension of the API. Personally I implemented it once or twice over the course of some years, but that's not something I need to have in the public API. I consider it as a convenience function I can easily implement on top of the already existing Resource API.
I would rather provide versions of the listChildren method which return streams (or any other method of the Resource API which returns a list or an iterator over resources). Jörg 2018-06-04 20:24 GMT+02:00 Jason E Bailey <j...@apache.org>: > At this point I'm looking for feedback to say whether there is a consensus > that the proposed API > > - stream() > - stream(Predicate<Resource>) > > where each one attempts to iterate through the tree is *sufficient enough > for the initial release*. I believe Stefan's concern was that he believed > someone encountering stream() on a resource would believe that it's only a > stream of the immediate children. > > I believe, he would prefer something like > > - treeStream() > > I'm inclined to see just stream() as the base method, as that's the > standard convention for a method that generates a stream. > > feedback appreciated. > Also there is a new pull request now that I've rolled everything back > https://github.com/apache/sling-org-apache-sling-api/pull/5 > > > > - Jason > > On Mon, Jun 4, 2018, at 2:02 PM, Jason E Bailey wrote: > > You got it. Thats's what I was attempting to describe and that's the > > type of filtering we do a lot of. > > > > - Jason > > > > On Mon, Jun 4, 2018, at 1:58 PM, Daniel Klco wrote: > > > It seems redundant, but I think they're somewhat different concepts. > The > > > Predicate passed into the stream method is for evaluating the Resources > > > relevant for traversal, whereas (at least I'm assuming) that any > subsequent > > > filters would filter the subsequent stream of resources. Having that > sort > > > of redundancy would allow you to traverse a structure like the > following: > > > > > > - myasset.jpg (dam:Asset) > > > - renditions (nt:folder) > > > - original (nt:file) > > > - rendition1.jpg (nt:file) > > > > > > so if you wanted to get just a stream of the nt:file resources you > could do: > > > > > > myassetResource.stream(maxDepth(2)).filter(isResourceType("nt:file")). > forEach(e > > > -> {DO_SOMETHING}); > > > > > > I like the idea of adding the predicates either in the API or as a > separate > > > dependency as there are likely a few common patterns that would be used > > > quite a bit. > > > > > > -Dan > > > > > > On Mon, Jun 4, 2018 at 1:31 PM, Jason E Bailey <j...@apache.org> wrote: > > > > > > > > > > > > > > > - Jason > > > > > > > > On Mon, Jun 4, 2018, at 12:35 PM, Daniel Klco wrote: > > > > > > > > > > > > > > Rather than having another parameter, what about providing a > > > > > ResourceChildrenPredicate? Based on the current API it looks like > you'd > > > > > have to provide the current resource to make this work, but it > seems like > > > > > it would be very useful to have a predicate which would only allow > for > > > > both > > > > > direct children or children up to a particular depth. I'd see it > useful > > > > to > > > > > provide 2-3 different default predicates to help with common > activities: > > > > > > > > > > ResourceChildrenPredicate - filter the stream of resources based > on their > > > > > child status > > > > > ResourceTypePredicate - filter the stream of resource based on > their > > > > > resource type > > > > > ValuePredicate - filter the stream of resources based on a value > in the > > > > > resource's ValueMap > > > > > > > > > > > > > > > > > > Funny you should mention this. The original ResourceStream object > came > > > > from the whiteboard streams project. Which has a whole package > dedicated > > > > to defining static predicates. There's even an expression languages > in > > > > their as well. However, for filtering, there's already a filter > method that > > > > a Stream provides. It's redundant to have a pre-filtered stream. > > > > > > > > However, as a limitation on the stream, you can do the same thing. It > > > > would something like > > > > > > > > - resource.stream(CHILD_RESOURCES); > > > > > > > > or > > > > > > > > - resource.stream(maxDepth(1)); > > > > > > > > maxDepth being a static method that you've imported from the > appropriate > > > > library that provides a Predicate > > > > > -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
