Storing Page-Specific Settings
This topic describes different possibilities to store page-specific settings.
Settings can be stored in the following scopes:
- Personalization: User-specific settings (These settings supersede Customizing and Configuration settings.)
- Customizing: Client-specific settings (These settings supersede Configuration settings, but can be superseded by Personalization settings.)
- Configuration: System-wide settings (These settings can be superseded by Customizing and Personalization settings.)
A page builder can store page-specific settings in the following locations:
- In properties of the page or a CHIP instance itself
- In a property bag that is assigned to the page or to a CHIP instance
Depending on the use case, you can decide which of these locations is more appropriate.
A page builder can store page-specific settings in the following locations:
- In the layout property of the page object
- In the layoutData property of a CHIP instance object
These properties are stored with the page or CHIP instance.
If you want to store more than one value in the layout or layoutdata property, you have to encode these values (for example, JSON.stringify()). Note that there is no merge mechanism for single attributes across different scopes.
For example, if you create a page or a CHIP instance in the Configuration scope and then modify the page or CHIP instance in the Customizing or Personalization scope, the system creates a copy of the page or CHIP instance as well as the layout or layoutdata property. If you then change the property in the Configuration scope again, these changes will not become visible in the higher scope where you modified the page or CHIP instance.
Property bags support merging of properties across different scopes.
For example, if you define the properties A, B and C in the Configuration scope and then modify property A in the Customizing or Personalization scope, the properties B and C will remain visible in that scope.