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 > >
