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 the various 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 example of such a method is generated by the Framework when we define an inbound plug into 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, the Framework 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.

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 it’s 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

In the context view, we create a context node named STUDENT, with the same structure as the data binding example –dictionary 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( ).
  lr_child_node_info = lr_node_info->add_new_child_node(
  name = 'STUDENT'
  is_singleton = abap_true
  is_multiple = abap_false
  is_mandatory = abap_true
  static_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 that’s why it is recommendable to use the 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 type – the name of the generated context node
• IS_SINGLETON of ABAP_BOOL type,default value ABAP_FALSE – sets the property node SYNGLETON.In our example,the node STUDENT has to be singleton,and that’s why we have set this value ABAP_TRUE
• IS_MULTIPLE of ABAP_BOOL type, default value ABAP_TRUE – sets the property node CARDINALITY.In our example,the node STUDENT has the cardinality 1...1,and that’s why we have set this value ABAP_FALSE
• IS_MANDATORYf ABAP_BOOL type,default value ABAP_FALSE - sets the same 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 type – we can use it to define the DICTIONARY_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).

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 don’t 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 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_LBL’
 label_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').
 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

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 an InputField 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 can’t create a data binding at design time, because this UI element doesn’t 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 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_NAME’bind_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

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 = ‘NAME’
  state = 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 don’t 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

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 doesn’t 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 don’t 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.

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.

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 option

The 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
  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,this parameter 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 two state 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 mandatory” active 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 mandatory”active.

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.

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 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 create two 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 didn’t enter his first name. In case of initial attribute, we call 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 named P_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

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

The onactionnext event handler method

 METHOD onactionnext .
 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_name
 p_node = lr_node).
 ENDIF.
 ENDMETHOD.

Runtime

Fire Methods

A Fire method is a special kind of method generated by the Framework when we define an outbound 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

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

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_<NAME_OUTBOUND_PLUG>_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

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 are special 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

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

Action and UI element

Let’s 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_<NAME_OUTBOUND>_PLG( ).

This method allows also parameter transfer

wd_this->FIRE_<NAME_OUTBOUND>_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 doesn’t enter a value in the inputField UI element.We will pass a reference to Message Manager from a view to 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

 METHOD onactionnext .
 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 don’t have the possibility to create a parameter for an Inbound Plug.In this case, we use the event handler method HANDLEIP_V_VIEW2 to read the value of the P_MM parameter.

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 doesn’t enter a value in the InputField UI element.