Hello, guys,
my colleagues and I are implementing a SPA application using AEM and Angular.
The decision we are currently facing is the following: where can we insert specific components so that they appear in more than one page (always in the same spot) without using the templates?
Components like these are the header, the footer, plus a bunch of other components specific for our SPA.
Previously, in the implementation that did not rely on Angular (and that was heavily server-side rendered), we would insert these components as:
<div data-sly-test.resourceType="resource/type/of/header}"
data-sly-resource="${'/content/path/to/homepage/jcr:content/header' @ resourceType=resourceType}"></div>
inside the HTML of the structure used by the templates of the pages we wanted to have the component.
So that, for example, our editors could go to the homepage, where they'd find the header-component and then configure it.
And the changes would propagate everywhere in the pages using the template, using the structure where the previous HTML was inserted.
Sadly, we are now restrictred to not use the structure of the editable templates much like we did before, because they are common between various SPA applications that have different specifics.
The obvious option would have been to place those components in the various implementations of editable templates used by our pages.
Unfortunately, our editors do not have access to the editable templates' console (/libs/wcm/core/content/sites/templates.html/conf) and, quite frankly, when suggested they did, refused to have access to it.
So basically we cannot place - for as I see it - the components: 1) in the structures, because those are shared by too many applications (and we are restricted in creating more); 2) and we cannot place them in the editable templates, because our editors won't access the console that would allow them to edit the components (such as the header).
Is there an option - somewhat AEM compliant, or that you would find advisable - to allow our editors to edit the components (say, the header or the footer) in a centralized way within the Sites console (so from /editor.html/content/path/to/page) and have those changes apply to those components across the site, without having to re-include/configure those components in every page?
We are also exploring the possibility of using Angular as aid, to inherit the components, but we see no way of allowing our editors to retain full customizability.
My team and I would immensly appreciate any input or idea you are willing to offer.
And as always, thank you guys for you contribution,
Parag Dalal.
Solved! Go to Solution.
Views
Replies
Total Likes
Have you explored using Experience Fragments? You can set up an Experience Fragment that represents the Header and then another XF that represents the Footer. The template can then reference these fragments and you would not have to give authors access to the template (just to the Experience Fragments). This is a technique that has become popular with full stack AEM sites and the Experience Fragments support automatic localization. The Angular Core Components contain an example of using Experience fragments: https://github.com/adobe/aem-angular-core-wcm-components.
Other useful resources: https://experienceleague.adobe.com/docs/experience-manager-core-components/using/components/experien...
Have you explored using Experience Fragments? You can set up an Experience Fragment that represents the Header and then another XF that represents the Footer. The template can then reference these fragments and you would not have to give authors access to the template (just to the Experience Fragments). This is a technique that has become popular with full stack AEM sites and the Experience Fragments support automatic localization. The Angular Core Components contain an example of using Experience fragments: https://github.com/adobe/aem-angular-core-wcm-components.
Other useful resources: https://experienceleague.adobe.com/docs/experience-manager-core-components/using/components/experien...
This seems very promising and I greatly appreciate your input.
We would have to get the approval of our authors, but I l very much ike the idea and regret not having thought about it myself.
I'll keep this post updated. Thank you so much.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies