Should HTL respect resourceSuperType?

[Chris Millar <cm...@apache.org>]

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

Re: Should HTL respect resourceSuperType?

[Bart Wulteputte <ba...@gmail.com>]

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 <cm...@apache.org>:

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