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