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 > > >
