Show TOC

Background documentationNotes on Working with Adaptation Data Locate this document in the navigation structure

 

Note the following information for the trouble-free use of adaptation 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 WDY_CONF_TRANSL_TEXT data element. Alternatively, you can create your own element that uses the WDY_CONF_TRANSL_TEXT domain.

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.

  • 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 IF_WD_PERSONALIZATION interface. This interface is provided by the Web Dynpro code wizard. Changes made directly to the context node cannot be recognized.