> > > Resource resolver is short lived, so caching there doesn't provide that > much value. You need something "global". I see, so the cache must be bound to something else. The only thing which comes to mind is the ResourceResolverFactory, but I would like to keep that new method and the method getResourceSuperType in the same interface (because one is just the inversion of the other). Any other idea except for a completely new OSGi service?
> > 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. I cannot think any other solution than those two. > > 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]
