Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Design Dialog Configuration in Different Templates.

Avatar

Level 2

Hi Everyone,

I have a component with design dialog configuration and I have various templates.

If I will configure the component in template 'A', the changes will reflect everywhere in component with same template, But the changes is not getting reflected in the component that I have placed in different templates say Template B, Template C etc..

I wanted to reflect the one time change in all the places where ever I have used the component. Template doesn't matter.

Kindly help me on this.

 

Thanks 

Renju Kesav

1 Accepted Solution

Avatar

Correct answer by
Level 8

If you want a guarantee that your configuration is going to be globally effective you really can't us the design mode to manage the configuration. There are strategies you can take to reduce duplication across templates but those are workarounds - design mode isn't intended to hold global configurations it's intended to hold design configurations specific to a particular location in the page or site. 

With a requirement like this you'll have to create some central location in your repository where you store this configuration and then fetch from that location using the Sling APIs. Normally what I do is pick a level in my site hierarchy to hold these configurations - for example the node immediately below /content, or perhaps you language/locale node. Depending on how many properties I'll either manage it in the page properties of that page, or create a config component to hold the properties. In my component then I'll usually use page.getAbsoluteParent to get the right page object, and then use the Sling Resource API to get to the right now and get the property value. 

You can also store the values in /etc somewhere if you wanted to. The advantage or storing it in your site hierarchy is that you can make your code self contained without any specific repository paths have to be hard coded.

You can also use a more inheritance based approach but that means you might be able to override those values at multiple levels. 

View solution in original post

1 Reply

Avatar

Correct answer by
Level 8

If you want a guarantee that your configuration is going to be globally effective you really can't us the design mode to manage the configuration. There are strategies you can take to reduce duplication across templates but those are workarounds - design mode isn't intended to hold global configurations it's intended to hold design configurations specific to a particular location in the page or site. 

With a requirement like this you'll have to create some central location in your repository where you store this configuration and then fetch from that location using the Sling APIs. Normally what I do is pick a level in my site hierarchy to hold these configurations - for example the node immediately below /content, or perhaps you language/locale node. Depending on how many properties I'll either manage it in the page properties of that page, or create a config component to hold the properties. In my component then I'll usually use page.getAbsoluteParent to get the right page object, and then use the Sling Resource API to get to the right now and get the property value. 

You can also store the values in /etc somewhere if you wanted to. The advantage or storing it in your site hierarchy is that you can make your code self contained without any specific repository paths have to be hard coded.

You can also use a more inheritance based approach but that means you might be able to override those values at multiple levels.