adobe / adobe/aem-project-archetype
Script 'xfpage/customheaderlibs.html' fails when core page component is customised
- Dominant language
- JavaScript
- Stars
- 596
- Forks
- 431
- Avg merge
- 10d 6h
- Merged PRs (30d)
- 1
Description
### Expected Behaviour
When doing page component customization based on:
https://experienceleague.adobe.com/en/docs/experience-manager-core-components/using/developing/customizing#customizing-the-logic-of-a-core-component
like this:
```java
@Model(
adaptables = SlingHttpServletRequest.class,
adapters = Page.class,
resourceType = {"acme/components/core/page"})
public class PageModel implements Page {
@Self
private SlingHttpServletRequest request;
@Self
@Via(type = ResourceSuperType.class)
private Page page;
// the rest of my customization
}
```
it has no chance to work on XFs which are assuming that `xfpage` is some kind of `page` , see: https://github.com/adobe/aem-project-archetype/blob/8e50a6d6d80b4eaa2c9706e195ecb6b241d63dbd/src/main/archetype/ui.apps/src/main/content/jcr_root/apps/__appId__/components/xfpage/customheaderlibs.html#L56
because for regular pages we have:
resource type => {appId}/components/page
resource super type => core/wcm/components/page/v3/page (this is fine, allows delegation)
but for experience fragments:
resource type => {appId}/components/xfpage
resource super type => cq/experience-fragments/components/xfpage (this is not correct, the super type is not core component page so that Sling Models injection will fail)
Wrapping up, I am expecting that AEM project structure generated from archetype will allow customisation of any core components without side effects like I just described related to XFs.
Probably 'customheaderlibs.html' and 'customfooterlibs.html' just have to load htmlPageItems on their own (not reusing core components page Java logic to fix the problem.
### Actual Behaviour
AEM project files generated from the archetype setup do not allow following the Core Components documentation regarding the extendability of the Core Page Component without fixing the XF problem on their own.
#### Platform and Version
Recent archetype files (51)
#### Logs taken while reproducing problem
```
org.apache.sling.scripting.sightly.SightlyException: Identifier com.acme.aem.core.components.page.PageModel cannot be correctly instantiated by the Use API
at org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:76) [org.apache.sling.scripting.sightly:1.4.22.140]
at org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:72) [org.apache.sling.scripting.sightly:1.4.22.140]
at org.apache.sling.scripting.sightly.apps.acme.components.xfpage.customheaderlibs__002e__html.render(customheaderlibs__002e__html.java:72)
at org.apache.sling.scripting.sightly.render.RenderUnit.render(RenderUnit.java:53) [org.apache.sling.scripting.sightly.runtime:1.2.6.140]
at org.apache.sling.scripting.sightly.impl.engine.SightlyCompiledScript.eval(SightlyCompiledScript.java:61) [org.apache.sling.scripting.sightly:1.4.22.140]
at org.apache.sling.scripting.core.impl.DefaultSlingScript.call(DefaultSlingScript.java:393) [org.apache.sling.scripting.core:2.4.8]
```
Contributor guide
Research direction
Start with ui.apps/src/main/content/jcr_root/apps/__appId__/components/xfpage/customheaderlibs.html at the referenced line, then compare it with customfooterlibs.html and the Core Component customization guidance. Reproduce the Sling Models instantiation failure using a customized page component and an experience fragment; done means both XF rendering and documented page-component customization work together without the reported error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100