view controller methods

7/30/2019 View Controller Methods

1/25

View Controller Methods

Abstract As we have seen in the previous chapters, in the Methods tab of a View we find

various types of methods generated by the Framework, and we can also create our own

methods. The purpose of this chapter is to present the role and the modality to use thevarious methods generated by the Framework and the modality to realize our own methods.

Each view has exactly one view controller. The view controller can contain

methods for data retrieval or for processing user inputs.

As we have seen, each view has a Methods tab where we can create our own user-defined

methods or we can find the methods generated by the Framework. In each Method tab of a

View, we can find or create three types of methods:

Event Handler: This kind of methods respond to actions or to events. An exampleof such a method is generated by the Framework when we define an inbound pluginto a View. Another example is a method generated from the Framework when we

create an action.

Method: We can use this kind of methods to create User-defined instance methods.Another example is the Hook Methods generated by the Framework.

Supply Function: When we create a node and define a supply function for it, theFramework generates a corresponding supply function method used to populate

with data a context node.

Hook Methods

These methods cannot be deleted and represent the interface between the Framework and

our application. The Hook Methods are called in a specific sequence according to a phase

model. After generation, these methods are empty, but can be filled with source codes in

case we want to interfere in a certain step of this phase model.

shows the Hook methods to be found in different controllers.


2/25

As we can see, the Hook methods wdDoInit and wdDoExit are common to all the

controllers. shows which Hook methods can be found in a view.

Hook methods in a view

wdDoInit

This method can be considered the controller constructor. It is automatically called when

the controller is initialized for the first time. We have many examples where we can use

this method, for example:setting the initial values of a controller context, dynamically

creation of a context node and attributes,filling context nodes.We can use this method

instead of the supply function method (to populate with values a context node),only if we

know that the context is filled only once and its not invalidated afterwards.

We create a WD component that uses the wdDoInit Hook method to populate with values a

context node. The component structure and the view layout are presented.

WD component structure, view layout


3/25

In the context view, we create a context node named STUDENT, with the same structure as

the data binding exampledictionary structure YSTR_PERSON,cardinality 1...1,singleton,

without supply function.

Context structure

Using the wdDoInit Hook method,we populate with values this node (Listing). When

calling the application for the first time, the wdDoInit Hook method fills the node

STUDENT with all the elements set here.

The wdDoInit Hook method

METHOD wddoinit .

DATA lr_node TYPE REF TO if_wd_context_node.DATA ls_data TYPE if_v_view=>element_student.

lr_node = wd_context->get_child_node('STUDENT').

ls_data-firstname = 'Antonia Maria'.ls_data-lastname = 'Keller'.

ls_data-dateofbirth = '19800306'.lr_node->set_static_attributes(ls_data).ENDMETHOD.

We can use the wdDoInit Hook Method to dynamically create the context nodeSTUDENT

and to populate it with values.

Runtime

The wdDoInit Hook method

METHOD wddoinit .DATA: lr_node TYPE REF TO if_wd_context_node,

lr_node_info TYPE REF TO if_wd_context_node_info,lr_child_node_info TYPE REF TO if_wd_context_node_info.

lr_node_info = wd_context->get_node_info( ).


4/25

lr_child_node_info = lr_node_info->add_new_child_node(

name = 'STUDENT'is_singleton = abap_true

is_multiple = abap_falseis_mandatory = abap_truestatic_element_type = 'YSTR_PERSON'

).

lr_node = wd_context->get_child_node('STUDENT').DATA ls_data TYPE ystr_person.ls_data-firstname = 'Antonia Maria'.ls_data-lastname = 'Keller'.

ls_data-dateofbirth = '19800306'.

lr_node->bind_structure(EXPORTING new_item = ls_data).

ENDMETHOD.

To dynamically create the context node STUDENT, we have used the

method ADD_NEW_CHILD_NODE of the IF_WD_CONTEXT_NODE_INFO

interface that creates an Info Object and adds it as a Lower-Level Node for the CONTEXT

root node. The method CREATE_NODEINFO_FROM_STRUCT of the

CL_ WD_DYNAMIC_TOOL class is obsolete and thats why it is recommendable to usethe if_wd_context_node_info->add_new_child_node.

ADD_NEW_CHILD_NODE have many import parameters of which,for the scope of our

example, we have used:

NAME of STRING typethe name of the generated context node IS_SINGLETON of ABAP_BOOL type,default value ABAP_FALSEsets the

property node SYNGLETON.In our example,the node STUDENT has to be

singleton,and thats why we have set this value ABAP_TRUE

IS_MULTIPLE of ABAP_BOOL type, default value ABAP_TRUEsets theproperty node CARDINALITY.In our example,the node STUDENT has thecardinality 1...1,and thats why we have set this value ABAP_FALSE

IS_MANDATORYf ABAP_BOOL type,default value ABAP_FALSE - sets thesame property node CARDINALITY.We need the ABAP_TRUE value because the

context node must have exactly one context element at runtime

STATIC_ELEMENT_TYPE of STRING typewe can use it to define theDICTIONARY_STRUCTURE property for our context node. Same as the case

when this node is created at the design time, we can use the name of the

development objects created in the ABAP Dictionary as Structure or Views

wdDoExit

This method can be considered the controller destructor. It is automatically called when

exiting the controller, and can be used for executing closing statements.

In the ABAP Dictionary, we have defined a lock for the database table YPERSON. We can

use wdDoExit Hook method to release a lock that has been set for this table to synchronize

the access of several WD applications to the same data. To do this, we have to use the

generated DEQUEUE_EYPERSON Function Module (Listing).


5/25

The wdDoExit Hook method

METHOD wddoexit .DATA lv_id_candidate TYPE yperson-id_person.

DATA lr_node TYPE REF TO if_wd_context_node.DATA ls_data TYPE wd_this->element_candidate.

lr_node = wd_context->get_child_node('CANDIDATE').lr_node->get_attribute( EXPORTING name = 'ID_PERSON'IMPORTING value = lv_id_candidate).

CALL FUNCTION 'DEQUEUE_EYPERSON'

EXPORTING

id_person = lv_id_candidate.ENDMETHOD.

Here we have called the Function Module directly from our WD method, but we can create

a method in a class used as model for theWDcomponent. If we dont call the corresponding

DEQUEUE_EYPERSON Function Module to release the database record that was locked

with the EQUEUE_EYPERSON Function Module, this lock is generally removed at the

end of the transaction.

wd Do Modify View

This method is mostly used in the dynamic programming, it is a method used for modifying

the view before rendering. For the dynamically programming of the UI elements, we have

many classes and methods that help us as application developer to dynamically modify a

view. To show this, we create an example, aWDcomponent, where we use this Hook

method to dynamically create an InputField, a Label, a TextView and a LinkToAction

UIelement. The WD component structure and the context node are presented.

WD component structure and context node

For the scope of this example, we import in the MIMEs (Multipurpose Internet Mail

Extensions) folder an image: next.JPG that we use for the linkToAction UI element. To

import a file in this folder, we right-click on the WD component name and, from the

contextual menu, we chooseCreate -> Mime Object -> Import.

The context node PERSON has the Cardinality 1. . .1, Singleton. Its attributes are NAME

and GREETING, of string type. We can almost use the same example as for our first


6/25

exercise. In this case, we create at design time only the UI element Group, the other UI

elements being dynamically created by using the wdDoModify- View Hook method.The

view layout is presented.

View layout

Listing shows the content of the wdDoModifyView Hook method By using the

FIRST_TIME parameter of WDY_BOOLEAN type, we check if wdDoModifyView is

called for the first time. In case this parameter is ABAP_TRUE (first time), we create a

label UI Element:

lr_label = cl_wd_label=>new_label(id = NAME_LBLlabel_for = NAME

text = NAME).

To do this, we use the method new_label of the cl_wd_label class interface

The WdDoModifyView Hook method

METHOD wddomodifyview .

DATA lv_bind_name TYPE string.DATA lv_bind_greeting TYPE string.

DATA lr_link_to_action TYPE REF TO cl_wd_link_to_action.

DATA lr_container TYPE REF TO cl_wd_group.DATA lr_flow_data TYPE REF TO cl_wd_flow_data.

DATA lr_input_field TYPE REF TO cl_wd_input_field.DATA lr_text_view TYPE REF TO cl_wd_text_view.DATA lr_label TYPE REF TO cl_wd_label.

IF first_time EQ abap_true.lr_label = cl_wd_label=>new_label(

id = 'NAME_LBL'label_for = 'NAME'text = 'NAME').

lr_flow_data = cl_wd_flow_data=>new_flow_data(element =

lr_label).

lr_container ?= view->get_element('GRP').lr_container->add_child(lr_label).lv_bind_name = 'PERSON.NAME'.

lr_input_field = cl_wd_input_field=>new_input_field(id = 'NAME'

bind_value = lv_bind_name).lr_flow_data = cl_wd_flow_data=>new_flow_data(element = lr_input_field).

lr_container->add_child( lr_input_field).

lr_link_to_action = cl_wd_link_to_action=>new_link_to_action(

id = 'LTA_LINKTOACTION'on_action = 'NEXT'image_source = 'NEXT.JPG').


7/25

lr_flow_data = cl_wd_flow_data=>new_flow_data( element =

lr_link_to_action).lr_container->add_child(lr_link_to_actio ).

lv_bind_greeting = 'PERSON.GREETING'.lr_text_view = cl_wd_text_view=>new_text_view(id = 'TXV_NAME'

bind_text = lv_bind_greeting).

lr_flow_data = cl_wd_flow_data=>new_flow_data(element =lr_text_view).lr_container->add_child(lr_text_view).ENDIF.

ENDMETHOD.

The new_label method has many mandatory and optional parameters. We have used

label_for, text and ID to set the main properties of the Label UI element. The text parameter

helps us to set the label text. The Label_for parameter specifies the UI element for which

this label is.

To embedding the UI elements into the layout, we need to specify the arrangement of these

elements. For this, we have used the FlowLayout layout:

lr_flow_data = cl_wd_flow_data=>new_flow_data( element = lr_label).

Class interface CL_WD_LABEL

Parameters for the new_label method


8/25

After creating the UI element and setting the layout, we have to attach them to the

ROOTCONTAINERUIELEMENT or to another container.In our case, we have attached

our new created label to the UI element Group with the GRP ID.

lr_container ?= view->get_element(GRP).lr_container->add_child(lr_label).

We have used the method add_child( ) that enabled us to do this.After this,we create anInputField UI element:

lr_input_field = cl_wd_input_field=>new_input_field(

id = NAME

bind_value = lv_bind_name).

We use the new_input_field method from the cl_wd_input_field class interface.The

bind_value parameter represents the value property for the UI element property.In this case,

we dynamically create a data binding for this property to the context node PERSON,

attribute NAME. Until now, we have seen how we can create a data binding at the design

time. In this case, we cant create a data binding at design time, because this UI element

doesnt exist at the design time; it is dynamically created at runtime.

To dynamically create a data binding of the property bind_value with the NAME attribute,

we have to specify the absolute path of this attribute. lv_bind_name = PERSON.NAME.

In the next step, we dynamically create a LinkToAction UI element:

lr_link_to_action = cl_wd_link_to_action=>new_link_to_action(id = LTA_LINKTOACTION

on_action = NEXT

image_source = NEXT.JPG).

We use the method new_link_to_action of the cl_wd_link_to_action class interface. This

UI element has an event associated. We have used the parameter on_action to define the

action that the Framework triggers when the user interacts with this UI element.

For a linkToAction UI element, we can define a hypertext link or we can use an image

instead a text.In our case, we have used the parameter image_source to specify the name of


9/25

the image we want to use. Then, we specify the layout and we attach it to our UI element

Group with the same GRP ID.

At the end, we dynamically create a TextView UI element by using the new_text_view

method of the cl_wd_text_view class interface

lr_text_view = cl_wd_text_view=>new_text_view(id = TXV_NAMEbind_text

= lv_bind_greeting).

The data binding to the context attribute GREETING is dynamically created.After creating

the UI element, we specify the layout and we attach it to our UI element Group with the

same GRP ID.

When the user presses the linkToAction UI element, the Framework triggers the event

handler method onactionnext(Listing ).

Action Next

The onactionnext event handler method

METHOD onactionnext .

DATA: lv_name TYPE string,lv_greeting TYPE string.DATA lr_node TYPE REF TO if_wd_context_node.

DATA ls_data TYPE wd_this->element_person.lr_node = wd_context->get_child_node( 'PERSON').lr_node->get_attribute(EXPORTING name = 'NAME'

IMPORTING value = lv_name).

CONCATENATE

'Welcome' lv_name INTO lv_greeting SEPARATED BY space.ls_data-greeting = lv_greeting.lr_node->set_static_attributes(ls_data).

ENDMETHOD.

Runtime


10/25

In case we want to set required the state property of the Input UI element, we need only

an extra line code:

lr_input_field = cl_wd_input_field=>new_input_field(id = NAMEstate = cl_wd_input_field=>e_state-required

bind_value = lv_bind_name).

We use the state parameter to dynamically set the property with the same name of the

InputField UI element.If we dont use this optional parameter, the default value is set:CL_WD_INPUT_FIELD=>E_STATE-NORMAL.

wd Do Before Action

We can use this method to perform our own validation before an action is triggered.To

exemplify this,we create a Web Dynpro component named Y_WDDOBEFOREACTION

with a view named V_VIEW and a window W_DEFAULT.

In the context view, we create the well-known context node named STUDENT,with the

same dictionary structure YSTR_PERSON, cardinality 1...1, singleton,without supply

function. Our scope is to check if the user enters values in all the in put Fields UI elements

bound to the attributes of the context node STUDENT. TheView layout is presented.

The View layout


11/25

In the wd Do Before Action Hook method, we use the static method

CHECK_MANDATORY_ATTR_ON_VIEW of the CL_WD_DYNAMIC_TOOL class

to check if the user had entered values in all the mandatory fields (the state property of the

inputField UI elements is set required).

The wdDoBeforeAction Hook method

METHOD wddobeforeaction .DATA lr_api_controller TYPE REF TO if_wd_view_controller.

DATA lr_action TYPE REF TO if_wd_action.lr_api_controller = wd_this->wd_get_api( ).lr_action = lr_api_controller->get_current_action( ).

IF lr_action IS BOUND.CASE lr_action->name.

WHEN SAVE.cl_wd_dynamic_tool=>check_mandatory_attr_on_view(view_controller = lr_api_controller).

ENDCASE.ENDIF.

ENDMETHOD.

When the user presses the Save button, the Web Dynpro Framework firstly checks,by using

the wdDoBeforeAction Hook method, if all the required fields are filled.In case the user

doesnt enter values in all these fields, all the operations that had to take place after

pressing the Save button are finished and the user is informed about this,through error

messages and by highlighting the UI elements that generated these messages. In this way,

we dont have to manually check each mandatory field.

Runtime

wd Do On Context Menu

We can use this method to provide hierarchical context menus in web Dynpro Views.In our

first example, we have already seen the default context menu displayed by the Web Dynpro

Framework when the user presses right-click on an UI element.


12/25

We can create a context menu at design time,by using the CONTEXT_MENUS root,or

dynamically, by coding the wd Do On Context Menu Hook method.To exemplify how we

can use this method to dynamically create context menus, we use the example from the

wdDoBeforeAction Hook method. In this case,we offer to the user the possibility to

personalize the field he wants to be mandatory. He will be able to choose between his first

name as mandatory field and his last name as mandatory field.

When he chooses the first name as mandatory,we will mark the corresponding field with a

red star, and when he chooses the last name, we will mark the corresponding field with a

red star. In the default mode, the first name is set as mandatory.

To create this example, we have to perform some modifications into the last application.In

this case,we have to set dynamic the state properties of the two inputField UI

elements,corresponding to first name and last name. To be able to do this, we have to

create, in the context view,two extra context attributes of WDUI_STATE type,to bind these

attributes with the corresponding properties. In this way, at design time, the two inputField

UI elements are not marked as mandatory,anyway. To set in the default mode the first name

as mandatory,we use the wdDoInit Hook method we have just learnt about.

Context structure and data binding

Setting the initial values for our node DYNAMIC

METHOD wddoinit .

DATA lr_node TYPE REF TO if_wd_context_node.DATA ls_data TYPE wd_this->element_dynamic.

lr_node = wd_context->get_child_node('DYNAMIC').ls_data-first_name = cl_wd_input_field=>e_state-required.

ls_data-last_name = cl_wd_input_field=>e_state-normal.lr_node->set_static_attributes(ls_data).

ENDMETHOD.

To offer to the end user the capability to dynamically choose what value he wants to be

mandatory from the two optional values, we have to code the wd Do On-ContextMenu

Hook method.


13/25

With the first data statement, we create a local reference to the CL_WD_MENU class and

two local references to the CL_WD_MENU_ACTION_ITEM, required to dynamically

create our menu,and two menu options of menuActionItem type. We need the two menu

options to offer to the user the possibility to choose between options:set first name as

mandatory or set last name as mandatory.

With the second data statement, we create two local variables required to read from the

context attributes the status properties corresponding to the two input-Fields UI

elements(firstname, lastname)and a local reference required to access our context

node. Firstly,we create a context menu by using the static method new_menu of the

cl_wd_menu class.

By using the static method new_menu_action_item of the cl_wd_menu_action_item

class, we create the two menu options we need.Fromthe parameters of this class,we have

used:

id: To set the ID of the view element on_action: To associate the action that will be triggered when the user presses the

respective option

text: The text that will be displayed for the respective menu optionThe wd Do On Context Menu example

METHOD wddooncontextmenu .DATA: lr_menu TYPE REF TO cl_wd_menu,lr_menu_item1 TYPE REF TO cl_wd_menu_action_item,

lr_menu_item2 TYPE REF TO cl_wd_menu_action_item.DATA: lr_node TYPE REF TO if_wd_context_node,

lv_first_name TYPE wdui_state,

lv_last_name TYPE wdui_state.lr_node = wd_context->get_child_node('DYNAMIC').

lr_node->get_attribute(EXPORTING name = 'FIRST_NAME'IMPORTING value = lv_first_name).

lr_node->get_attribute(EXPORTING name = 'LAST_NAME'IMPORTING value = lv_last_name).lr_menu = cl_wd_menu=>new_menu(id = 'CONTEXT_MENU').

IF lv_first_name = 01 AND lv_last_name = 00.lr_menu_item1 = cl_wd_menu_action_item=>new_menu_action_item

id = 'LAST_NAME'on_action = 'LN_MANDATORY'

text = 'Set last name as mandatory').

lr_menu_item2 = cl_wd_menu_action_item=>new_menu_action_item

id = 'FIRST_NAME'on_action = 'FN_MANDATORY'text = 'set first name as mandatory'enabled = abap_false).

ELSEIF lv_first_name = 00 AND lv_last_name = 01.lr_menu_item2 = cl_wd_menu_action_item=>new_menu_action_item

id = 'FIRST_NAME'on_action = 'FN_MANDATORY'text = 'set first name as mandatory').

lr_menu_item1 = cl_wd_menu_action_item=>new_menu_action_item


14/25

id = 'LAST_NAME'

on_action = 'LN_MANDATORY'text = 'Set last name as mandatory'

enabled = abap_false).ENDIF.lr_menu->add_item(the_item = lr_menu_item1).

lr_menu->add_item(the_item = lr_menu_item2).

menu = lr_menu.ENDMETHOD.

enabled: To set if this option is active or inactive. In the default mode,thisparameter is set ABAP_TRUE,respective enabled

The local variables used to pass the values of the two attributes (firstname and lastname)

are of the same type as the attributes: WDUI_STATE.By doubleclicking on the TYPE,the

forward navigation is open and we can see a data element with a Domain as an elementary

type.This domain has two fixed values:00 for Normal item and 01 for required.

Before we effectively create the two menu options, we have to check which one of the twostate proprieties is set required and which one is set normal.In case the firstname is required

and lastname is normal,we create the two menu options with Set last name as mandatoryactive and Set first name as mandatory inactive.In case the firstname is normal and the

lastname is required,we create the two menu options with Set last name as mandatory

inactive and Set first name as mandatoryactive.

Then, we add the two created menu options of menuActionItem type to our context menu

and display the respective menu by using the wdDoOnContextMenu Hook method,

returning the parameter named menu. we have already seen that, for our InputFields UI

elements, we have set the properties:

context Menu Behaviour: Provides, not inherits from the container context Menu Id: Set with the IDs of our context menu options

Runtime

All we have to do now is to create the respective actions: FN_MANDATORY and

LN_MANDATORY,actions that the Framework triggers when the user presses our menu

action items. The onactionln_mandatory event handler method is presented.


15/25

Event handler method triggered for the menu option with LAST_NAME ID

method ONACTIONLN_MANDATORY .DATA lr_node TYPE REF TO if_wd_context_node.

DATA ls_data TYPE wd_this->element_dynamic.lr_node = wd_context->get_child_node('DYNAMIC').

ls_data-first_name = cl_wd_input_field=>e_state-normal.ls_data-last_name = cl_wd_input_field=>e_state-required.lr_node->set_static_attributes(ls_data).

endmethod.

In case the user chooses the last name as mandatory, we have to set required the property

state of the corresponding UI element and normal the property state of the UI element

corresponding to the first name.

The onactionfn_mandatory event handler method is presented in Listing In case the user

chooses the first name as mandatory, we have to set required the property state of the

corresponding UI element and to set normal the property state of the UI element

corresponding to the last name.

Event handler method triggered for the menu option with FIRST_NAME ID

method ONACTIONFN_MANDATORY .DATA lr_node TYPE REF TO if_wd_context_node.

DATA ls_data TYPE wd_this->element_dynamic.

lr_node = wd_context->get_child_node('DYNAMIC').ls_data-first_name = cl_wd_input_field=>e_state-required.

ls_data-last_name = cl_wd_input_field=>e_state-normal.lr_node->set_static_attributes(ls_data).

endmethod.

Runtime

Supply Function Methods

We have used this type of methods every time we have assigned a supply function to a

context node, every time we have populated the context attributes of the context nodes with

initial values via supply function. When a controller is called, these methods are called


16/25

first. We have seen that a supply function can be assigned to each context node of a

Controller.

Context node and supply function

The Framework generates a corresponding supply function method.An alternative for the

supply function methods can be the wdDoInit Hook method, if we know that the context is

filled only once at initialization and it is not invalidated afterwards.

Supply function

User-Defined Instance Methods

In the Methods tab, we can create our own user-defined methods with or without

parameters. After creating a user-defined method, we can call it in the same controller, by

using the wd_this self reference.

In this case, we copy our example from the wdDoModifyView Hook method and we createtwo extra user-defined methods:

A method named GREETING that has two import parameters A method named PERFORM_VALLIDATION that has one import parameter

In the ONACTIONNEXT event handler method, we check whether the attribute NAME is

initial, respective if the user didnt enter his first name. In case of initial attribute, we call


17/25

our own defined PERFORM_VALIDATION method. By using this method, we show an

error message. In case this attribute is not empty, we call our own defined GREETING

method to create a greeting for the end user.

The user-defined GREETING method. As we can see, this method has defined an

importing parameter named P_NAME of STRING type and an importing parameter namedP_NODE of ref to if_wd_context_node type. The P_NAME parameter holds the value of

the NAME attribute.

The user-defined PERFORM_VALIDATION method. As we can see, this method has an

importing parameter named P_ELEMENT, referable to the interface

IF_WD_CONTEXT_ELEMENT.

In this case, we have used the method REPORT_ATTRIBUTE_ERROR_MESSAGE of the

interface IF_WD_MESSAGE_MANAGER to report a Web Dynpro error message to a

context attribute.

The ONACTIONNEXT event handler method. As we can see, the local variable lv_name

holds the value of the NAME attribute. If this attribute is empty, we have to show an error

message. To do this, we use our own defined PERFORM_VALIDATION method.

User-defined GREETING method

User-defined PERFORM_VALIDATION method


18/25

wd_this->perform_validation(EXPORTING p_element = lr_element). If this attribute is notinitial, we use its value as exporting parameter for our own defined method GREETING.

The onactionnext event handler method


DATA lr_node TYPE REF TO if_wd_context_node.

DATA ls_data TYPE wd_this->element_person.DATA lv_name TYPE string.

DATA lr_element TYPE REF TO if_wd_context_element.lr_node = wd_context->get_child_node('PERSON').lr_element = lr_node->get_element( ).

lr_node->get_attribute(EXPORTING name = 'NAME'

IMPORTING value = lv_name).IF lv_name IS INITIAL.wd_this->perform_validation(EXPORTING p_element = lr_element).

ELSE.

wd_this->greeting(EXPORTING p_name = lv_namep_node = lr_node).

ENDIF.ENDMETHOD.

Runtime


19/25

Fire Methods

A Fire method is a special kind of method generated by the Framework when we define anoutbound plug.We need inbound plugs and outbound plugs to define the navigation

between two views.These plugs are the entry and the exit point for each view. We create an

example,a WD component that has two Views. The WD component structure is presented.

WD component structure

In this case, we want to navigate from the view V_VIEW1 to the view V_VIEW2, when

the Framework triggers an event handler method, respective when the user presses a

button. In the COMPONENTCONTROLLER,we create a context node PERSON,

Cardinality 1...1,Singleton and one attribute NAME of string type.

Context structure


20/25

The data stored in the context of the component controller are used within the two views

V_VIEW1 and V_VIEW2, through context mapping.

View V_VIEW1 layout

View V_VIEW2 layout

When the user presses the Next button,we want to navigate from the view V_VIEW1 to the

view V_VIEW2.The view V_VIEW1 will be replaced with the view V_VIEW2. This

navigation is possible through a navigation link between the views, in the window.

Plugs and navigation

To set up navigation between our views, we must create an inbound plug for the view

V_VIEW2 and an outbound plug for the V_VIEW1. In the Outbound Plug tab of the view

V_VIEW1, we create an outbound plug named OP_TO_V_VIEW2.

Out bound plug


21/25

In the Inbound plug tab of the view V_VIEW2,we create an inbound plug named

IP_V_VIEW2.

In bound plug

When the user presses the Next button,the Framework triggers the event handler method

onactionnext.Every time we create an outbound plug for a view,a special method is added

to its interface. This method has the statement

FIRE__PLG. To fire this method, we can use the Web

Dynpro CodeWizard or select an outbound plug when creating an Action.

The event handler method has the following statement:

METHOD onactionnext .wd_this->fire_op_to_v_view2_plg( ).

ENDMETHOD.

Creating an action


22/25

We use the self-reference WD_THIS of the view controller to fire the method

FIRE_OP_TO_V_VIEW2_PLG that was added to this interface when we have created the

outbound plug.

All the views within a window can be connected to each other by using navigation links.To

be able to create the navigation,we embed the views in the window and then we drag &drop the outbound plug to the inbound plug. We can also create navigation by right-

clicking on the output plug name.

Creating navigation link

At runtime, when the user interacts with the view V_VIEW1, his interaction will cause a

request to the server.In response, the view V_VIEW1 will be replaced with the view

V_VIEW2. This is possible through the navigation link defined between these views.

Event Handler Methods

An event handler method responds to actions or to events. We have used this type of

methods every time we have assigned an action to an UI element.This kind of methods arespecial methods of a view controller that has the prefix ONACTION followed by the action

name. As we have seen,the action is defined in the Action tab and the corresponding event

handler method is generated by the Framework.

Action and event handler method


23/25

We can assign an action to an UI element that has an event, indifferent if this UI element iscreated dynamically or at the design time.

Action and UI element

Lets create an example where we use an event handler method implemented to respond to

events of inbound plugs!

We have seen that the outbound plugs are the starting point of navigation, called in any

method of the view controller by using the statement:

wd_this->FIRE__PLG( ).

This method allows also parameter transfer

wd_this->FIRE__PLG(PARAMETER = value).

In this case, the PARAMETER has to be entered in the parameter table of the view

controller. For a better understanding,we create the same example as for the fire methods,

but in this case we show an error message when the user doesnt enter a value in the

inputField UI element.We will pass a reference to Message Manager from a view to


24/25

another view, via an outbound parameter. In the View_1 we add in the parameter table,on

the Outbound plug,a parameter named P_MM.

Defining the parameter for an Outbound Plug

When the user presses the Next button, the Framework triggers the event handler method

onactionnext.

Event handler method


DATA: lr_api_controller TYPE REF TO if_wd_controller,lr_api_manager TYPE REF TO if_wd_message_manager.

lr_api_controller ?= wd_this->wd_get_api( ).lr_message_manager = lr_api_controller->get_message_manager( ).wd_this->fire_op_to_v_view2_plg( p_mm = lr_message_manager).

ENDMETHOD.

Inbound plug

We dont have the possibility to create a parameter foran Inbound Plug.In this case, we use

the event handler method HANDLEIP_V_VIEW2 to read the value of the P_MM

parameter.


25/25

When an inbound plug is called, the handler method that is uniquely assigned to this

inbound plug is called. This method is automatically generated in the view controller when

the inbound plug is created.We find this method in the Methods tab of the view V_VIEW2.

Event handler method

The value of the parameter P_MM is passed by the outbound plug OP_TO_V_VIEW2. To

be able to read the value of this parameter, we have to add the parameter P_MM to the

signature of the event handler method assigned to the inbound plug,i.e.the

HANDLEIP_V_VIEW2 event handler method.

Event handler method. Implementation

In this way, the value of the P_MM parameter is known by the event handler method and

can be used to send a message in case the user doesnt enter a value in the InputField UIelement.

view controller methods

Documents