Hi Chris,
Without some more code my current understanding of the situation might be
wrong. Using your example where I renamed the extending component for
clarity:
experience-cloud/components/myExtendingComponent
|__ myExtendingComponent.html
and properties:
sling:resourceSuperType="dexter/components/myComponent"
AND
dexter/components/myComponent
|__ myComponent.html
|__ myTemplate.html
Without knowing what your call to
experience-cloud/components/myComponent/myTemplate.html looks like, I'm
guessing it looks somewhere along the lines of this:
<sly
data-sly-use.lib="experience-cloud/components/myExtendingComponent/myTemplate.html"
data-sly-call="${lib.myTpl @ param1='x'}"/>
Sling evaluates the following candidates (I've left out the /lib
counterparts for simplicity) :
/apps/experience-cloud/components/myExtendingComponent/experience-cloud/components/myExtendingComponent/myTemplate.html
/apps/dexter/components/myComponent/experience-cloud/components/myExtendingComponent/myTemplate.html
Most likely these paths aren't available. Changing the setup to:
<sly data-sly-use.lib="myTemplate.html" data-sly-call="${lib.myTpl @
param1='x'}"/>
Sling evaluates the following candidates (I've left out the /lib
counterparts for simplicity) :
/apps/experience-cloud/components/myExtendingComponent/myTemplate.html
/apps/dexter/components/myComponent/myTemplate.html
Now you would be able to use the template from the sling:resourceSuperType
in your myExtendingComponent, or even override it you wanted to.
Note that there is one other solution which you could use. This is a common
pattern for 'shared' templating libraries instead of local ones:
<sly data-sly-use.lib="/apps/dexter/components/myComponent/myTemplate.html"
data-sly-call="${lib.myTpl @ param1='x'}"/>
I hope this was clear enough, if you mean something else by your original
statement I would like to see some more code.
Best regards
Bart
Op za 6 apr. 2019 om 01:25 schreef Chris Millar <[email protected]>:
> If you have:
>
> experience-cloud/components/myComponent
>
> that extends:
>
> dexter/components/myComponent
>
> and you attempt to call:
>
> experience-cloud/components/myComponent/myTemplate.html
>
> when that file only exists in the resourceSuperType.
>
> Sling / HTL will kindly let you know that resource does not exist.
>
> My question is; is this the desired result?
>
> What's interesting is that HTL data-sly-call *does* respect certain base
> Sling features like resourceResolver resolution fallbacks of /apps ->
> /libs. But it doesn't support this other use case.
>
> While I think the current Impl makes sense, I could see scenarios where it
> might not for others. It does create more duplicate code because someone
> who extends will absolutely have to write that file to the JCR.
>
> Thoughts?
>
> Chris
>
