Working Dynamically with Parameter Mappings Dynamic Programming Programming Web Dynpro ABAP

The term parameter mapping is used for the bind of an event parameter to a parameter of an action handler method.

Background

A number of UI elements is able to trigger events. Each of these events has predefined parameters; for example, every event has the parameter ID. Depending on the type of the related UI element, other parameters may additionally be predefined. However, these event parameters are not represented individually in the development environment; for a complete list of all events and their related parameters for every UI element, see the reference part of this documentation.

In the handler method of the action related to the event, you can now use this event parameter by creating a parameter with the same name for the method. The mapping between these two parameters always occurs via similarity of names (see also Parameter Mapping in the fundamental part of this documentation).

Example: Every event has a parameter ID, to which the name of the respective UI element is assigned as value. If you create a parameter named ID in the handler method of the related action, the value of the event parameter with the same name is automatically passed to it.

Dynamically Creating Additional Event Parameters

You can create and use other parameters besides the event parameters predefined by the meta model. However, this procedure is applicable only within the frame of dynamic programming.

Adding additional event parameters must always be implemented in the method WDOMODIFYVIEW.

Example

A view contains several UI elements of type LinkToAction. The link the user activates controls the subsequent display within the view. Depending on the selected link, an attribute (for example, with the name ”CLICKED_AT”) of the view context must receive a specific value. The handler method of the only action (for example, with the name ”ON_CLICK”) of this view copies this value from the respective event parameter, which has been created for each of these UI elements and has been added dynamically to the respective event.

For this procedure, you must perform the following three steps:

· Create the additional parameter

· Set its value which depends on the UI element

· Assign the parameter to the respective event.

The coding below shows these three steps for the example above:

METHOD wddomodifyview. DATA: lt_parameters LIKE if_wd_event=>parameters, parameter LIKE LINE OF lt_parameters, lr_link1 TYPE REF TO cl_wd_link_to_action, lr_link2 TYPE REF TO cl_wd_link_to_action. .

First, for method WDOMODIFYVIEW two variables are declared: one for the event parameters to be newly created and one for the local table that administers them. In addition, you need a variable of corresponding type for each of the UI elements.

. . CHECK first_time = abap_true. lr_link1 ?= view->get_element( 'LINK1' ). lr_link2 ?= view->get_element( 'LINK2' ). . .

The parameter view is automatically known in each method WDOMODIFYVIEW. The two local variables are assigned by means of the related interface IF_WD_VIEW and the ID (Link1/Link2) of the respective UI element.

. . parameter-name = 'MYID'. parameter-value = 1. parameter-type = 'g'. INSERT parameter INTO TABLE lt_parameters. lr_link1->map_on_action( lt_parameters ). . .

Then the new parameter receives a name, value and type and is added to the local table. If you want to add several parameters to the event of this UI element, repeat the last three steps as often as required and also add the additional parameters to the local table.

Use the command lr_link1->map_on_action( lt_parameters ) to link the local table to the event.

. . CLEAR lt_parameters[]. parameter-name = 'MYID'. parameter-value = 2. parameter-type = 'g'. INSERT parameter INTO TABLE lt_parameters. lr_link2->map_on_action( lt_parameters ). ENDMETHOD.

After resetting the local table, the steps are repeated for the second and all other events.

As the result of this procedure, the events of the two UI elements Link1 and Link2 each contains a parameter named MYID, however with different values. When the respective event is triggered, the runtime automatically passes the new parameter to the action handler method, by which it is evaluated appropriately.

A simple variant of the action handler method ONACTIONON_CLICK could look like this:

Parameter Declaration type Reference type WDEVENT Importing CL_WD_CUSTOM_EVENT MYID Importing STRING

METHOD onactionon_click. wd_context->set_attribute( name = 'CLICKED_AT' value = myid ). ENDMETHOD.

The value of the event parameter MYID is passed to the context attribute CLICKED_AT and can now be used for further control.