If you look at the target use cases
https://sling.apache.org/documentation/bundles/sling-query/vs-jcr.html
Almost everything that is listed as use "JCR-Query" is what I use the resource
locator for. So, as far as I'm aware, they are complimentary .
I also took a different approach to the API. The resource locator was built
around the Stream API and predicates. You don't even need to use the
ResourceLocator object
Example
aChildResource("jcr:content").has(property("sling:resourceType").isNot("sas/components/page/folder")))
creates a java.util.function.Predicate<Resource> object that could be used any
where you need to filter a stream of resources, like a stream() from a
Collection. The filter language creates a Predicate<Resource> object as well.
I haven't checked sling-query yet but my filter language does a lot of heavy
lifting for you. Handles arrays, conversions between types etc.
>From a performance perspective, I experienced faster results from the
>ResourceLocator then using a JCR2-SQL query.
- Jason
On Thu, Jan 25, 2018, at 4:19 PM, Stefan Seifert wrote:
> hallo jason.
>
> this looks a bit like sling-query [1], although the syntax is a bit different.
> how do you compare those two approaches?
>
> stefan
>
> [1] https://sling.apache.org/documentation/bundles/sling-query.html
>
>
> >-----Original Message-----
> >From: Jason E Bailey [mailto:[email protected]]
> >Sent: Thursday, January 25, 2018 6:35 PM
> >To: [email protected]
> >Subject: Gauging interest on Yet Another Way to Find Resources
> >
> >Another one of my side projects
> >
> >https://github.com/JEBailey/sling-resourcelocator
> >
> >I think there's enough difference between other ways of finding
> >resources that there's value to bringing it in. But I like feedback,
> >since I'm a bit prejudiced.
> >It works by creating a Java8 Stream of resource objects starting from a
> >resource that you provide and iterating through descendants based on
> >provided criteria.
> >1. Handles limits, ranges, and depth
> >2. Control traversal path by setting conditions on which child resource
> > can be included3. Can define complex acceptance criteria for resources
> >based on
> > properties4. Definable via fluid api or a filtering language
> >5. filtering language is extensible using custom functions
> >
> >And because it uses resources it's resource provider agnostic.
> >
> >- Jason
> >
>
