I was going through https://docs.adobe.com/docs/en/aem/6-3/develop/the-basics/designer.html document which highly recommends to store images and CSS files under /etc/design/<project>. The reasoning given is that re-designing of the website can be simply done by pointing the design path to a different node at the root of the site from design/v1 to design/v2. A code snippet for an image was given there, however when we talk about re-designing, this is more than just using different images (which we can anyways do using inherited parsys) and mostly comes down on how to switch ClientLibs for a particular section of the site. I was not able to use this Design and Designer to do so since ClientLibs are included based on category and not on the path. So unless I use a naming convention which is more of a custom code, I am not able to switch ClientLib by asking my marketer to just change the design path. Am I missing something here please?
Solved! Go to Solution.
Views
Replies
Total Likes
When using the template editor you can also specify the clientlibs there.
Those can then be specified to switch or implement a new design.
Views
Replies
Total Likes
When using the template editor you can also specify the clientlibs there.
Those can then be specified to switch or implement a new design.
Views
Replies
Total Likes
Here a screenshot from We.Retail on aem6.3 (edit template -> page design)
Views
Replies
Total Likes
Views
Replies
Total Likes
Thanks so much Feike. Appreciated.
Good to know that we can swap clientlib at template level but my question was more specific to a content hierarchy. Would this suffice that use case as well? Consider a brand having multiple themes- men, women and kid and giving the option to author to choose specific clientlib for men sub-hierarchy than women. Also even if this work why to marketer 2 different configurations- one for design path and other for clientlibs while both could be driven by a single property which makes it lot more simpler and IMHO nothing better than design path here.
Would love to hear your feedback.
Views
Replies
Total Likes
You can have multiple ways here, but you can of course store the clientlibs you want to use also at jcr:content level.
Then using the inheritedPageProperties you can request the property.
This way you can override the setting at each level.
Views
Replies
Total Likes
Hi Feike,
Yes that is the approach, we have taken so far where-in we are storing ClientLib name at page property and then using inheritedPageProperties, getting this value to do a cq:includeClientLib. But as you see, to make this working author has to set 2 properties to make this work- design path and then clientlib name, also this looks to me a custom clientLib resolution. Since Design path is the one which looks to me more appropriate as we are talking about swaping one design vs. other here, is there anything out of the box, we can use for this use case? If there is none, is there a ClientLib API which I can use to set the searchpath for includeClientLib for example for Men pages, I will use the searchpath to men design path which I will automatically get in my code because AEM/Sling already sets that. That way it will be a clean solution and author doesn't need to maintain 2 separate properties.
Thanks again for your prompt response!
Views
Replies
Total Likes
How can the Page Design option be enabled if it doesn't already exist?
Views
Replies
Total Likes
Please check this answer:
aem - What is the use of designDialogPath? - Stack Overflow
Adding cq:design_dialog to page component resolves this.
In my core components version (2.0.6) it exists in core/wcm/components/page/v2/page but not in core/wcm/components/page/v1/page
Views
Replies
Total Likes
Thanks, it turned out my issue was tied to the version of something I had installed that was hiding the Page Design option. I was able to get it figured out.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies