Resource resolver is short lived, so caching there doesn't provide that much value. You need something "global".
Most clients of resource resolver do not care about resource types at all, so adding more stuff to that interface doesn't make it nicer for most use cases of resource resolver. A solution which is only limited to JCR is imho not a good idea and putting the burden on resource providers is as you point out too much effort and not necessary. Resource type inheritance is a cross cutting concern. Regards Carsten Konrad Windszus wrote > 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] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
