Notes on Working with Adjustment Data 

There are a number of points to note to ensure the appropriate use of adjustment data.

Configuration Data

The following rules apply for the configuration context created by the developer of the component:

●     Attributes must be of a simple type (no references or table structures)

●     The context structure should not be changed at runtime

●     The context must not contain any recursive nodes

●     The context should not contain any singleton nodes

●     The context should specify a primary attribute for every multiple node

 

If the value of an attribute is a text that is to be translated into different languages, you can use the element WDY_CONF_TRANSL_TEXT. Alternatively, you can create your own element that uses the domain WDY_CONF_TRANSL_TEXT. 

A data element that was created for the configuration cannot be deleted by customizing. If you want to implement an option for hiding individual elements when devising the configuration at design time, you must add an additional attribute to the context with the semantics “visible”, for example. In the customizing process, you can then control the visibility of individual elements via this attribute.

 

Changing Values of the Configuration Context

There are different ways of changing the value of an element of the configuration context at runtime.

●     If the element is bound directly to a UI element that can be edited by the user (for example, an input field), the personalization framework recognizes the value change automatically.

●     However, if the value of the element is changed programmatically – for example, in a method call – the personalization framework only recognizes the change if it was implemented using the interface IF_WD_PERSONALIZATION. This interface is provided by the Web Dynpro code wizard. Changes made directly to the context node cannot be recognized.