Why do you want to separate it from the ResourceResolver interface? From a consumer perspective this sound like the perfect fit. In the ResourceResolveImpl we can then implement such a cache (but this would be an implementation detail and not part of the API).
I am thinking about a best effort approach like querying recursively with SQL2. Of course this would only return results for the JCR Resource Provider (but I think that is sufficient for 99% of the cases). Another approach would be to require every Resource Provider to provide that information and I think this is too much of an effort for right now. Later on we can easily extend/improve the implementation by extending the Resource Provider interface. WDYT? > On 12. Jan 2018, at 15:25, Carsten Ziegeler <[email protected]> wrote: > > I think some time ago we discussed a separate resource type mgmt service > (which also could cache resource type resolution). > > Maybe now is a good time to think about it and introduce it? > > Regards > > Carsten > > > Konrad Windszus wrote >> Yes, exactly. >> But if someone has a better idea on how to achieve that I am eager all ears. >> >>> On 12. Jan 2018, at 15:19, Jason Bailey <[email protected]> wrote: >>> >>> So that I understand, this would benefit a scenario where you are searching >>> for a specific resource type, and the search implementation would have to >>> traverse up the resourceType hierarchy to determine if a specific type was >>> of a type that you are looking for. >>> >>> One of the solutions for this, as you suggest, could be a pre-emptive >>> determination of the derived types and then the search implementation could >>> compare against that. >>> >>> Did I get that right? >>> >>> -----Original Message----- >>> From: Konrad Windszus [mailto:[email protected]] >>> Sent: Friday, January 12, 2018 5:46 AM >>> To: [email protected] >>> Subject: Re: Search for specific resource types >>> >>> EXTERNAL >>> >>> Ping, does anyone have any idea? >>> >>> I am thinking about introducing a new method to ResourceResolver which >>> allows to return all derived resource types for a given resource type. That >>> must internally rely on a search within /apps and /libs looking for >>> resourceSuperType=<given type> recursively! >>> >>> Such a method could be used as a basis for the query to look for content of >>> type "a" or a derived type. >>> WDYT? >>> >>> Konrad >>> >>>> On 15. Dec 2017, at 16:59, Konrad Windszus <[email protected]> wrote: >>>> >>>> Hi, >>>> is there a simple way to search with Sling Resource API for resources >>>> which have a certain resource type "a" or a resource type derived from "a". >>>> The resource type inheritance in Sling is a pretty powerful concept. I am >>>> wondering how to properly support that when searching for content which is >>>> either of resource type a directly or a derived resource type. >>>> >>>> I cannot really think of a JCR SQL2 or XPath expression which would also >>>> cover derived resource types (without knowing them in advance). >>>> Thanks for any pointers, >>>> Konrad >>> >> > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
