java - How is sling:resourceSuperType is impacting sling resolution? -
hi going through how sling resolution works.
i came against scenario mentioned on adobe aem-developer guide
https://docs.adobe.com/docs/en/aem/6-2/develop/the-basics.html
this scenario mentioned- / ( not have resource supertype or resource type)
b (sling:resourcesupertype = a)
c (sling:resourcesupertype = b)
x (sling:resourcetype = c)
y (sling:resourcetype = c, sling:resourcesupertype = a)
the type hierarchy of /x [ c, b, a, ] while /y hierarchy [ c, a, ] because /y has sling:resourcesupertype property whereas /x not , therefore supertype taken resource type.
now understand how /x resolved. not sure /y. first resolved /c. had sling:resourcesupertype b. should sling resolution not go /b well. how supertype overriden , resource resolved instead of b.
as explained in apache sling documentation, if sling:resourcesupertype defined particular resource, used. if it's not present, framework use sling:resourcesupertype defined resource pointed sling:resourcetype.
that said, in case of /y, /b not treated super type. sling:resourcesupertype defined /y points directly /a. hide sling:resourcesupertype property defined @ /c (and pointing @ /b) otherwise taken account.
the example quite described on documentation page linked to.
in experience, custom aem components easier maintain if resource type hierarchy defined set of nodes defining component , present in repository descendants of /apps or /libs (when including ootb components in inheritance hierarchy). specific instances of components (including ones responsible rendering whole pages) present in /content sub-tree can unambiguously define sling:resourcetype determines type (inheritance or not). personally, prefer not define sling:superresourcetype @ level of resource that's part of /content sub-tree makes hierarchy more difficult reason about. off top of head, can't think of use case justify trade-off. perhaps else weigh in if know one. 
Comments
Post a Comment