- 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

Reply via email to