I agree with removing Resource.getResourceSuperType() (i.e. Carsten's original point a)), and the usage (or interpretation) of the "sling:resourceSuperType" property on content nodes (i.e. nodes located outside the search path(s)). This should lead to a stable hierarchy that is cacheable.
Also, providing a service to access the resource type hierarchy (that allows caching) is IMHO a good idea (i.e. Carsten's original point d)). We need to find adequate API signatures, but let's assume we can achieve that ;) However, currently I do not agree with moving the definition of the hierarchy to a dedicated location (i.e. Carsten's original points b) and c)). In order to make it easier to inspect the hierarchy (i.e. Carsten wrote "it's easy to find out the hierarchy by looking into the resource tree"), we could let the service expose the resource hierarchy as a resource tree (ResourceProvider), powered by the same in-memory cache that the service might use. Alternatively, a consolidated tree could be automatically written into the repository and the service could use that to initialize its cache. (My preference would be the former, because keeping two physical structures in sync is error prone). Regards Julian On Mon, Mar 21, 2016 at 1:28 PM, Jason Bailey <jason.bai...@sas.com> wrote: > There is a third use case from a presentation perspective, which is the 'is > a' use case. Is this resource a resource of resource type 'foo' > > -----Original Message----- > From: Konrad Windszus [mailto:konra...@gmx.de] > Sent: Friday, March 18, 2016 4:42 AM > To: dev@sling.apache.org > Subject: Re: [RT] Improve resource type handling > > For me it would help a lot to quickly reconsider the current situation. > As far as I know resource super types are used for two different things in > Sling right now: > > 1. Script resolution: Influences which script is being picked up (initially > or via includes from other scripts), documented in > https://sling.apache.org/documentation/the-sling-engine/url-to-script-resolution.html#base-resource-type-inheritance > 2. Resource merging: For the override resource merger > (http://sling.staging.apache.org/documentation/bundles/resource-merger.html#overriding-resource-picker-override-approach) > > The problem is that for 1. the resource super type may be defined at two > different locations: > a) having a sling:resourceSuperType property in the node referencing the > resource type > b) having a sling:resourceSuperType property in the node addressed by the > resource type compare with https://issues.apache.org/jira/browse/SLING-278. > > a) is really confusing because a) may overwrite b) and that resource type > inheritance is used only for script resolution. To simplify thing I would > suggest to just get rid of a). Who is using a)? > > Regarding the proposal having a dedicated resource subtree where the > inheritance would be declared sounds overly complicated to me. It feels much > more natural to define the super type directly on the resource implementing a > certain resource type. > > For content merging it would feel more natural to have a generic resource > inheritance concept. So something like "superResource" (rather than > resourceSuperType). > That way it feels more natural that this may be used for 1. only on resources > implementing a resource type and 2. for resources defining some content. > I would expect that this super resource is always defined on the resource to > which it applies (not in a dedicated part of the resource tree). > > WDYT? > Konrad > > > > >> On 18 Mar 2016, at 09:09, Oliver Lietz <apa...@oliverlietz.de> wrote: >> >> On Friday 18 March 2016 08:08:55 Carsten Ziegeler wrote: >>> Hi, >> >> Hi Carsten, >> >>> in the past years we added a lot of things here and there which over >>> time resulted in cruft and sometimes hard to understand / debug >>> problems. In order to have an even better framework which is easier >>> to manage but also scales better for the things to come, we should >>> get rid of this additional weigth. >>> >>> One area which I think needs attention is the resource type handling. >>> We started years back with the two methods on a resource, getting a >>> resource type and optionally getting a resource super type. >>> A little bit later this was extended with what we call today the >>> resource type hierarchy: for a resource type a/b, a resource can be >>> created in /libs/a/b with a resource super type property. This can be >>> overlayed in /apps. (I'm assuming the default search paths here to >>> keep it simple). >>> >>> While this sounds nice and and simple, it has several drawbacks (in >>> no particular order): >>> - it's hard to find out all the super types of a resource type >>> - the resource resolver which reads the type hierarchy needs read >>> access to the complete tree of /libs and /apps - just to find a few >>> properties here and there. >>> - two resources with the same resource type, might have different >>> resource super types or even a complete different hierarchy. >>> - there is no guarantee that the resource super type is static, which >>> means two calls to find the super type for a resource type could >>> result in different results, e.g. if the resource itself decides to >>> return a different value, or if a resource decorator is used which does so. >>> - for traversing the hierarchy we currently create an additional >>> admin resource resolver per resource resolver - which is a huge overhead. >>> >>> Especially the last three points make improving the script resolution >>> hard - if not impossible. Today the cache is using the resource type >>> and resource super type of the resource as a key. However, given the >>> above information it is easy to create a scenario where the cache >>> returns a wrong script. >>> >>> Taking all these things into account, I think we should somehow start >>> fresh with handling the resource type hierarchy and come to a better >>> solution. In this first step, I think we should not care about >>> compatibility. Once we have a great solution, we'll find a way on how >>> to achieve this. >>> >>> My rough initial proposal would be: >>> a) forget about Resource#getResourceSuperType. This method is ignored >>> from now on (and deprecated) >>> b) the resource hierarchy is not spread across /libs, /apps anymore >>> c) we create a dedicated resource tree at /foo (I'm using /foo as a >>> placeholder as I don't want to start an endless discussion now on >>> what this path actually really is). We then have /foo/apps and /foo/libs. >>> Underneath each of these resources, there is a flat list of resources. >>> Each resource is associated with a resource type (through the name of >>> the resource) and has two properties: resource type and resource super type. >>> d) we create a service which has three methods >>> >>> // get the super type >>> String getResourceSuperType(ResourceResolver resolver, String >>> resourceType); // get an ordered list of all super types List<String> >>> getResourceSuperTypes(ResourceResolver resolver, String >>> resourceType) >>> // check if resourceType is checkResourceType (either directly or one >>> of the parents) boolean isResourceType(ResourceResolver resolver, >>> String resourceType, String checkResourceType) >>> >>> We pass in the resource resolver to this service in order to pass in >>> the search paths and the current user rights. This should allow us to >>> continue with this service, even if we add tenant support at a later >>> time or do some other checks. >>> >>> With this approach we have >>> a) a clear resource type hierarchy which is stable. A resource of >>> type A has always the same resource super types. (unless the >>> hierarchy is changed of course) >>> b) the service reading the hierarchy only needs read access in a >>> single place >>> c) it's easy to find out the hierarchy by looking into the resource >>> tree >>> d) the hierarchy can easily be cached in memory >>> >>> WDYT? >> >> I don't get c): "flat list of resources" and "find out the hierarchy >> by looking into the resource tree". Can you give an example? >> >> Thanks, >> O. >> >>> Regards >>> Carsten >> >> >
