Dynamic Programming Programming Web Dynpro ABAP

Web Dynpro offers the frame for you to lay out the user interface structures of your business application as declarative as possible. Nevertheless, with increasing complexity of the application, it may become necessary to make certain decisions only at runtime.

The dynamic embedding of an interface view into a window in the context of a dynamically created component usage is an example for dynamic programming within a Web Dynpro application. In addition, you may influence, for example, the structure of a context at runtime; you may add elements to a context at runtime.

Besides, you can change the layout of a view at runtime, which means that you can dynamically add UI elements.

Dynamic Layout Manipulation Dynamic Programming Programming Web Dynpro ABAP

Under certain conditions, it may be useful to change the layout of a view at runtime. In this context, you can add as well as remove UI elements. You can also change the dynamic properties of a UI element, bind an event to an action or manipulate the Parameter Mapping of Event Parameters.

Basically, you should use the dynamic manipulation of the layout – just like the dynamic manipulation of the context – only if it is not possible to construct a component by declarative means. This may be the case if parts of the component are not yet knows at design time.

To make changes to the structure of a view layout, you must use the method WDDOMODIFYVIEW (or a method called within it).

For a complete list of all UI element classes and their methods, refer to the reference part of this documentation.

Containers and UI Elements

To use the dynamic layout manipulation correctly, you must understand the structure of a view: In a view, a number of UI elements is laid out in relation to one another. This is done in so-called containers. To describe it, a layout is selected for every container: FlowLayout, MatrixLayout, or RowLayout exist (see reference documentation, chapter Layout). Every UI element has layout data, in accordance with the embedding container. This layout data contains the description, at which position in the layout of the container an embedded UI element has its place.

The layout of the container and the layout data of the embedded UI element must always match. Example: If the container is of type FlowLayout, then the layout data of the embedded UI elements must be of type FlowData.

When a view is created, it already contains an empty container, the ROOTUIELEMENTCONTAINER. Within this container, the entire view layout is structured.

Adding a UI Element to a Container

To add a new UI element to a UI element container, proceed as follows:

● You must determine what kind of a UI element it is.

● For the container element to which to add the new UI element you must create a reference (method view->GET_ELEMENT).

● You must determine the position in the container layout, where to fit in the new element. For this purpose, you must create the layout data for the newly created UI element.

The code fragment below shows the steps required to add a UI element of type Button:

method WDDOMODIFYVIEW . data: LR_CONTAINER type ref to CL_WD_UIELEMENT_CONTAINER, LR_BUTTON type ref to CL_WD_BUTTON, LR_FLOW_DATA type ref to CL_WD_FLOW_DATA. LR_BUTTON = CL_WD_BUTTON=>NEW_BUTTON( ). LR_FLOW_DATA = CL_WD_FLOW_DATA=>NEW_FLOW_DATA( element = LR_BUTTON ). LR_CONTAINER ?= view->GET_ELEMENT( 'ROOTUIELEMENTCONTAINER' ). LR_CONTAINER->ADD_CHILD( LR_BUTTON ). . . endmethod.

Properties of the Newly Added UI Element

If you want to set a property of the UI element during the dynamic creation, pass the values when you create the element. To enhance the above example with a text on the button to be created (the text has been created before in the Online Text Repository):

data: MY_TEXT type string. MY_TEXT = CL_WD_UTILITIES=>GET_OTR_TEXT_BY_ALIAS( 'MY_TEXT_ALIAS' ). LR_BUTTON = CL_WD_BUTTON=>NEW_BUTTON( text = MY_TEXT ).

A property like the text of the button can also be used later. For this purpose, the class CL_WD_BUTTON, and all other basis classes of UI elements, contains the appropriate method – for the example above, this is the method SET_TEXT. In the same manner, you can set or change all other properties of a UI element. For example, you can assign an action (which you created independently) to the button or change the assignment dynamically.

LR_BUTTON = CL_WD_BUTTON=>NEW_BUTTON( text = MY_TEXT On_action = MY_ACTION ).

Besides, you can bind properties of UI elements to context nodes. To do this, the class CL_WD_[UI element type] contains a set of methods BIND_[property type]:

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.

Dynamic Context Manipulation Dynamic Programming Programming Web Dynpro ABAP

You can manipulate the context of a controller in different ways at runtime.

To support the dynamic programming of contexts and view layouts, the Web Dynpro framework offers a number of methods in the service class CL_WD_DYNAMIC_TOOL. This class contains the frequently used methods in a predefined form. However, you can also implement yourself all the methods for dynamic context manipulation implemented in this class within the Web Dynpro framework. However, note that not all technically possible options are available in this class. In many cases, you will carry out your programming via the relevant framework interfaces to be able to use advanced functions.

To get an overview of how this class is used, have a look at the example component DEMODYNAMIC in the SWDP_DEMO package, which was delivered together with your system.

Adding Context Nodes

Adding a node to a context at runtime may be necessary for a variety of reasons. In highly generically programmed components, the number of required nodes may not be known at design time. Even if the number is known, the structure of the node may become known only at runtime. In such a case, the node is also created and typed dynamically.

For this purpose, the interface IF_WD_CONTEXT_NODE_INFO contains the method ADD_NEW_CHILD_NODE, which has a number of parameters, such as the name of the new node or the assigned supply method.

Alternatively, the service class CL_WD_DYNAMIC_TOOL contains the method

CREATE_NODEINFO_FROM_STRUCT, but with limited functionality.

If you delete the node info, then all instances of the related node are automatically deleted as well.

In contrast to statically created context nodes, the length of the name of a dynamically created node is not limited.

The Attribute Structure of the Node

The method CREATE_NODEINFO_FROM_STRUCT expects a known structure to be passed, which means that the node created in such a way automatically has a fixed set of attributes in accordance with the selected structure. However, you can always add individual attributes to this structure (see below). Basically, you could also dynamically create an empty node and fill it with attributes afterwards. However, the service class CL_WD_DYNAMIC_TOOL does not provide a prepared method for this.

Binding a UI Element to a Dynamically Created Context Node

The dynamic bind of a UI element to a context node is programmed at the UI element (see chapter Dynamic Layout Manipulation).

Adding Context Attributes

It can make sense to add or remove parameters to or from a context node, depending on the parameters evaluated at runtime. If you created a context node with a DDIC structure at design time, you can create additional attributes only dynamically. In generic applications it may happen that the type of an attribute is not yet known at design time; in this case, you will also create and type this attribute dynamically.

For this purpose, the interface IF_WD_CONTEXT_NODE_INFO contains the method ADD_ATTRIBUTE.

Fixed Values of Attributes

A UI element can be bound to a dynamically created context node. The UI element may access fixed values of context attributes. In this case, it is necessary to determine fixed values for the attributes. For more information, see Fixed Values of Attributes.

Method Call in a Dynamically Created Component Usage Web Dynpro ABAP Dynamic Programming

If a used component of the using component wants to provide a method to be called, this method must be defined in the interface controller of the used component.

In practice, the method to be called is generally declared in the interface controller of an interface definition and programmed in the component controller of an implemented component. The code fragment below shows a section of a method of a view controller of the using component:

method MY_CONTROLLER_METHOD . data: L_INTF_CONTROLLER type ref to IWCI_, L_COMPONENT_USAGE type ref to IF_WD_COMPONENT_USAGE. L_INTF_CONTROLLER ?= L_COMPONENT_USAGE->GET_INTERFACE_CONTROLLER( ). L_INTF_CONTROLLER->( ). . . endmethod.

L_COMPONENT_USAGE is a reference to the dynamically created component usage. L_INTF_CONTROLLER is a reference to the interface controller of the used component/component interface.

Showing posts with label Dynamic Programming. Show all posts Dynamically Registering an Event Handler to an Event Web Dynpro ABAP Dynamic Programming

Components you use within another component can have events. An event of an interface definition is triggered in the component in which the interface definition is implemented.

An event handler of the using component can register onto such an event. If the usage of a component has been created dynamically, then also the registration of the using component onto an event of the used component or the implemented interface must be created dynamically. The code fragment below shows an example of how to implement a dynamic registration.

method MY_CONTROLLER_METHOD . data: L_COMPONENT_API type ref to IF_WD_COMPONENT, L_COMPONENT_USAGE type ref to IF_WD_COMPONENT_USAGE. L_COMPONENT_API = WD_COMP_CONTROLLER->WD_GET_API( ). L_COMPONENT_USAGE->ADD_EVENT_HANDLER( listener = L_COMPONENT_API handler_name = controller_name = 'INTERFACECONTROLLER' event_name = ). . . endmethod.

The method ADD_EVENT_HANDLER ( ) is called at the object of the component usage L_COMPONENT_USAGE. The attribute controller_name describes the controller in which the event is defined: If, as described here, the event is defined in a used component, then it can only be the interface controller of this component.

The method you want to implement in the registration must be called in the Phase Model of the Web Dynpro framework at a point in time before the call of the method that triggers the event.