!--a11y-->
Dynamically Creating Component
Usages 
The chapter on Component Usage Without Controller Access already mentioned that, depending on the purpose of the application, it may be useful to display a particular interface view of a component more than once within a using component. If the number of embeddings is constant and known at design time, the structure of the embedding window can be constructed statically. However, if the application developer of the using component does not yet know at design time how many usages are needed at runtime, the generation of the component usages can be programmed dynamically. The code fragment below shows a section that might be implemented in a method of the component controller of the using component:
method MY_CONTROLLER_METHOD .
data: L_COMPONENT_USAGE type ref to IF_WD_COMPONENT_USAGE, L_MY_INITIAL_USAGE type ref to IF_WD_COMPONENT_USAGE.
L_MY_INITIAL_USAGE = WD_THIS->WD_CPUSE_MY_INITAL_USAGE( ).
L_COMPONENT_USAGE = L_MY_INITIAL_USAGE->CREATE_COMP_USAGE_OF_SAME_TYPE( <NAME_OF_THE_SECOND_USAGE> ). . . endmethod.
|
First, a first usage must be created statically, before at runtime other usages of the same component (....USAGE_OF_SAME_TYPE) can be generated dynamically out of it. The above example shows the creation of a second component usage. If the number of the usages needed later is not yet know at design time, this step must be programmed in an appropriate loop.
The created component usages can be managed in an internal table, an attribute of the controller. This attribute must be created explicitly for that purpose. To do this, the Web Dynpro runtime offers the type WDAPI_COMPONENT_USAGE; however, you can also create a data type of your own.
In many applications, it may be necessary to dynamically create the usage of different components. For example, in an international application the usage of the respective country-specific component may be created only after the user entered the country code. In this case, the component to be used is not known at runtime. Instead of the usage of a different component, you can now declare the usage of a separate component interface. The programming is done as shown in the above example. All components to be embedded into the using component must implement the respective component interface at design time. At runtime, now any number of usages of the interface can be created. The assignment of the actual implementation to each of the usages is done only when the respective component is instanciated (see section Instanciating Used Components in Component Usage Without Controller Access). In this case, the name of the component to be instanciated is programmed as a variable and passed at runtime.
If you want to embed an interface view of a component included dynamically in the way described above you must program this embedding dynamically as well. For more information see Dynamically Embedding an Interface View.
Instead of managing dynamically created component usages in an internal table at the component controller, you can also use component usage groups. The concept of the component usage groups integrates the management of the dynamically created usages into the Web Dynpro runtime.
A component usage group is always created in the using component, preferably at the component controller. The code fragment below shows how a component usage group is created dynamically.
method MY_CONTROLLER_METHOD .
data: L_CMP_API type ref to IF_WD_COMPONENT, L_CMP_USAGE_GROUP type ref to IF_WD_COMPONENT_USAGE_GROUP.
L_CMP_API = WD_THIS->WD_GET_API( ).
if L_CMP_API->HAS_CMP_USAGE_GROUP( ‘TESTGROUP’ ) is initial.
WD_THIS->CMP_USAGE_GROUP = L_CMP_API->CREATE_CMP_USAGE_GROUP( NAME = ‘TESTGROUP’ USED_COMPONENT = ‘<name used component>’). endif. . . |
Into this dynamically created usage group you can now add component usages:
WD_THIS->CMP_USAGE_GROUP->ADD_COMPONENT_USAGE( NAME =’USAGE1’ EMBEDDING_POSITION = ‘<Name View>/<Name Container>’ USED_COMPONENT = ‘<Name used component>’ ).
WD_THIS->CMP_USAGE_GROUP->ADD_COMPONENT_USAGE( NAME =’USAGE2’ EMBEDDING_POSITION = ‘<Name View>/<Name Container>’ USED_COMPONENT = ‘<Name used component>’ ).
. . |
For the values of parameter EMBEDDING_POSITION there is a convention: If the selected container itself also contains a view, the further specification is separated with a period from the specification of the outer view/outer container:
EMBEDDING_POSITION = ‘<Name View>/<Name Container>.<Name Sub-view>/<Name Container2>*’
|
You can repeat this nesting several times.