Working Dynamically with Parameter Mappings

The term parameter mapping refers to binding an event parameter to a parameter of an action handler method.

A number of UI elements are 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: UI Elements.

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. These two parameters are always mapped using similarity of names (see also Parameter Mapping).

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.

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 link clicked, an attribute (for example, with the name CLICKED_AT) of the view context must be given 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.

The following steps are necessary for this procedure:

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 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, two variables are declared for method WDOMODIFYVIEW: one for the new event parameter itself and a second for the local table for its administration. 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_link2->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:

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.