Hi Robert, I'll need to clarify the documentation.
The ResourceFilter is the object that converts a String to a Predicate<Resource> , there are cases where you want the ResourceFilter Script to evaluate against a provided java object, The ResourceFilter object has methods to add objects to the context that the parsed script is ran against. Because of that, I choose to make the ResourceFilter Object maintain state. Since it maintains state, I needed a provider to create a unique instance of ResourceFilter. I couldn't just do new ResourceFilter() because I need to encapsulate and separate the parser references and I eventually will be adding an ability to define new functions for the ResourceFilter Script by way of additional services. - Jason On Tue, Aug 21, 2018, at 5:20 AM, Robert Munteanu wrote: > Hi Jason, > > Thanks for re-starting the vote with an updated version. > > Like the last time, I have some API questions :-) > > The README only describes adapting a Resource to a > ResourceStreamFilter, which is nice and idiomatic for Sling. > > On the other hand, there are more classes exported as API in > org.apache.sling.resource.filter, see [1] . > > Are these necessary? What are the use cases for them? > > IMO the way it's currently done is not bad by any means, I'm just > trying to understand whether we need the extended API or not. > > Thanks, > > Robert > > > [1]: > https://github.com/apache/sling-org-apache-sling-resource-filter/blob/master/src/main/java/org/apache/sling/resource/filter/ResourceFilterProvider.java > >
