Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

AEM 6 - Sightly Page Component + Inheritance

Avatar

Level 8

Good morning.
We have a base page component written using sightly, with a sling:resourceSuperType of "wcm/foundation/components/page".  We then have another page component, let's just call it "page_component" that has a sling:resourceSuperType which is the base page component.  When i create a page with the base page component, everything works correctly, however, when I create a page using the "page_component", I get the following error:

"Caused by: io.sightly.java.api.SightlyUseException: Required script resource could not be located: head.js"

Obviously the entire error is longer, but that's the important line.   With page components previously, the inheritance of files would go back to the ootb component.  That doesn't seem to be the case with sightly and the use of javascript files.  Is this the intended behavior and i need to create a local head.js file, or is there an extra step that needs to be taken with a sightly page component?

Thanks in advance.

1 Accepted Solution

Avatar

Correct answer by
Level 1

This has been confirmed as a bug. A work-around may be, as mentioned by @orotas, to use absolute paths in data-sly-use.

View solution in original post

12 Replies

Avatar

Level 10

Are you following AEM docs or another on-line resource?

Avatar

Correct answer by
Level 1

This has been confirmed as a bug. A work-around may be, as mentioned by @orotas, to use absolute paths in data-sly-use.

Avatar

Level 8

I do not know of any documentation that exists regarding this particular topic.  

Avatar

Level 1

Is there an issue tracker or similar system associated with this bug that we can follow to get updates when it is fixed?

Avatar

Level 8

So I just went through recreated the same issue. I think to summarize the issue I'd say that the problem is that data-sly-use does not seem to have the same file inheritance logic that <cq:include script=".." /> did. The specific use case I went through looked like this:

  1. Create a template /apps/geometrixx/templates/extend_template and a page component for that template at /apps/geometrixx/components/extend_text. Set the sling:resourceSuperType of this component to be wcm/foundation/components/page. Create now Slight scripts at first - just create the template and have it inherit everything from it's parent. 
  2. Create a template /apps/geometrixx/templates/local_extension_template and a page component for that template at /apps/geometrixx/components/local_extension. Set the sling:resourceSuperType of this component to be geometrixx/components/extend_text. Create now Slight scripts at first - just create the template and have it inherit everything from it's parent.
  3. Create pages based on each template and open them. Both pages render without issue.
  4. Copy /libs/wcm/foundation/components/page/page.html to /apps/geometrixx/components/extend_text/extend_text.html and change nothing. 
  5. Reload both pages, everything continues to load without issue. 
  6. Copy /libs/wcm/foundation/components/page/head.html to  /apps/geometrixx/components/extend_text/head.html and change nothing. 
  7. The page based on  /apps/geometrixx/components/extend_text renders without issue, the page based on /apps/geometrixx/components/local_extension throws the exception that it can't find head.js - which head.html includes using data-sly-use - data-sly-use.head="head.js". 

So the issue is that data-sly-include works as expected (which is why overriding page.html with extend_text.html did not cause an issue), however data-sly-use does not seem to support the same deep inheritance, it seems to only support on level of inheritance. 

This seemed validated when I was able to resolve the issue by changing data-sly-use.head="head.js" to be data-sly-use.head="/libs/wcm/foundation/components/page/head.js" and error was resolved (although the next data-sly-use statement in the file failed so you would have to make all the date-sly-use references absolute.

The documentation on data-sly-use doesn't specify one way or the other what the expected behavior is. Looking at http://docs.adobe.com/docs/en/aem/6-0/develop/sightly.html#use it says that the expectation is that file is in the same directory as the slightly script. That doesn't quite match the real behavior where the inheritance works one level down however. The documentation on data-sly-include doesn't may any mention of the expected inheritance behavior (http://docs.adobe.com/docs/en/aem/6-0/develop/sightly.html#include). 

I am not sure if this is intentional or a potential bug. 

Avatar

Employee

This issue is tracked internally (GRANITE-6589 - "data-sly-use in parent component does not load script overlaid in inherited component"), we'll try to keep this thread updated when some fixes will be available. But we don't have a date defined yet for an update, meaning that it won't happen so soon.

Avatar

Level 4

Hi,

checking release notes of the latest service pack (http://docs.adobe.com/docs/en/aem/6-0/release-notes-sp1.html) I found this

"Fixed an issue in cluster that Workflow launcher rules, when changed, are not reloaded on all cluster nodes. GRANITE-6337"

Is that one the same issue reported in this topic?

 

Thank you

Avatar

Level 4

Ok. However, I was not referring to 6337 but to: The data-sly-use statement recognizes the scripts defined at two or more levels up in the inheritence tree. GRANITE-6404 (SP1).

Avatar

Level 2

This issue is fixed with SP1 for AEM 6

Avatar

Employee

And GRANITE-6404 (data-sly-use in parent component does not load object overlaid in inherited component) will be fixed in SP2, which will be released in January 2015.

Avatar

Level 9

We are facing this issue after upgrading from AEM 6.0 SP3 to AEM 6.2.

What we supposed to do in this case??

Please advise me.

Thanks,

Kishore