How would I access a component on another page's node that is included in the current page via structure and data-sly-resource?



I have a bit of a thorny issue.

I have a component (we'll call it trouble-component) that is configured only once on a page, let's say the home page.

The presence of the component in that page is overridden with data-sly-resource in the structure (we'll call it generic structure) that is used by that very page (home page and many other pages), so that each page using that structure will contain that resource which was added to the home page in a fashion similar to the following:

<sly data-sly-resource="${'/content/path-to-homepage/jcr:content/trouble-component' @ resourceType='my-project/components/content/trouble-component'}"></sly>


This produces the desired outcome, which is that:

  • the home page contains the node trouble-component
  • the component is configured in the home page and that configuration is spread across in every other page that uses that resource, thanks to the data-sly-resource in the structure generic structure.
  • all pages with a generic structure include the component


Now the issue.

Due to the way this is configured, the only page node containing (in its jcr:content, or below) the trouble-component is the home page and when I use a Model Exporter to map and export the properties of the other pages which use generic structure, even though the page itself will contain the trouble-component, it's corresponding JCR node will not, so that - and this is the issue - the Model Exporter will not expose the content of trouble-component when exporting/mapping any other page that is not home page.


How can I - when exporting the JCR representation of the node of a page (via Sling Model Exporter, for example, or in any other way) that extends generic structure and thus will contain the trouble-component, export the configuration of the trouble-component that is centralized in the home page?

I realize this is a bit of a thorny question and I hope I have made myself clear.
If a more appropriate architecture is to be contemplated in order to:

  • centralize the configuration of a trouble-component only in one page
  • have that same configuration and component used coherently in all other pages with structure generic structure
  • be able to export a representation of each page node including the trouble-component without singularly include the trouble-component in each of those pages

I am more than willing to contemplate a different solution.


In the meantime, I am grateful for whatever input, advice or insight you'll be able to provide,

Parag Dalal.

Accepted Solutions (1)

Accepted Solutions (1)




If I understand you correctly, some external logic (outside of the trouble-component) know where to get that content for that trouble-component from. But this logic is not reflected in the Sling-Model-Exporter, because SME does not know anything about that specific logic.


If my assumption is correct, I see the problem in the fact, that the functioning of this component depends on many different aspects working together (the external logic, the trouble-component, and now also the SME). In your case I would concentrate all the logic into the trouble-component. Instead of some external logic writing that data-sly statement with the correct resource path, add this logic to the trouble-component, and then you handle that inclusion also when the SME is exporting the model for the trouble-component.


Does that make sense?

Answers (2)

Answers (2)




Hi @parag_dalal ,


The component you are refering to "trouble component" is to be configured only once and then to be used in all the pages. You can achieve such a usecase with experience fragment. You can configure such components on experience fragments and include the experience fragment component on the structure of page so that it appears on all pages.


Here are the useful refrences to understand experience fragments:


Hope it helps!