Konrad Windszus wrote > 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)? > Thats part of my proposal.
> 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. I see it differently :) It right now complicates everything. I would also try to move the scripts out of /libs, /apps. There is a lot of things in these trees. If you think of operation systems, you have a search path for your commands, and each path only contains scripts but not all the additional stuff. > > 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). > I haven't looked into the resource merging use case, as this has been added on top of the already complicated mechanism Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
