registration
Sap Abap Web Dynpro

Sap Abap Web Dynpro

This course contains the basics of Sap Abap Web Dynpro

Course introduction
Interview Questions
Pragnya Meter Exam

Sap Abap Web Dynpro

User Interface Elements (UI elements) Static and Dynamic Programming

The UI elements we can use in the Web Dynpro ABAP are divided in various categories.In this chapter, we are going to present some of the UI elements, included in the categories:action, selection,layout, complex, graphic and integration. Each UI element will be illustrated by an example,showing the modality of using it either in static or in dynamic variant.

A UI element is a User Interface element we use to create a screen for the end user. The UI Elements are grouped in categories we can access via the View Layout,and each UI Element has some properties, as follows

  • Common with other UI elements,inherited from superclasses
  • Specific only for an UI element
  • For example, the following properties are inherited:
  • Tooltip: Shows a quick info text when the user passes the mouse pointer over the UI element
  • Visible: Determined if an UI element is visible in the screen or not
  • Enabled: Specified if the UI element is active or inactive

By using the Class Builder transaction SE24, we can see different classes along with their inheritances and attributes. For example, the class CL_WD_UIELEMENT is the super class of all the UI elements we use in Web Dynpro ABAP. Being super class, this class has CL_WD_VIEW_ELEMENT. presents the tooltip,visible and enable properties for an InputField UI element.

Most of the UI elements properties can be bound to different context nodes or attributes.In this way, we can manipulate the UI elements via the data held in the context. Each bindable property of a UI element has a certain type. For example,the enabled property can be bound to an attribute of WDY_BOOLEAN type.

when this attribute is set ABAP_TRUE, the respective UI element is active.When this attribute is set ABAP_FALSE, the respective UI element is inactive.

The UI elements, along with the aggregations, determine the appearance and behaviour of the UI elements on the screen. The Web Dynpro UI elements are divided in categories. Hereunder, we present some of these categories.

Graphic

This category contains UI elements that help us to work with graphics maps,etc. Hereunder,we present some of the UI Elements included in this category.

Image

This UI element enables us to integrate graphics in our WD application. Same as other UI elements, it has some properties. Hereunder,we show a table with some of the Image UI element properties that can be bound,and the attribute type in case the property is bindable.

Some of the Image UI element properties

We create a WD Component, where we can choose among three images and we can manipulate the current image via the data held in the context.The WD component structure is presented.

WD component structure

We import three images in JPG format.As we have mentioned,to import an image into a MIME folder,we have to choose Create Mime Object Import from the contextual menu,shown by right-clicking on the WD component name.

The context node DYNAMIC is Singleton, cardinality 1...1. The attributes WIDTH and HEIGH are STRING type and the attribute BORDER is I type. We use these attributes to manipulate the properties of the Image UI element. For the attributes WIDTH,BORDER and HEIGH, it is defined the data binding to the properties (with the same names) of the UI element Image.

Context structure and data binding

The context node DROPDOWNBYINDEX has the dictionary structure SHSVALSTR2,cardinality 0...n,Singleton.We have defined a data binding between the attribute KEY and the property texts of the dropDownByIndex UI element. The attribute VALUE is used to manipulate the property source of the Image UI element.This property defines the name of the image file shown on the screen.

View Layout structure

To populate with values the context attributes of the context node DROPDOWNBYINDEX, we use the supply function method shown in the Listing.

Supply function method

 METHOD supply_dropdownbyindex.
 DATA:
 ls_image TYPE wd_this->element_drop down by index,lt_image LIKE TABLE OF ls_image.
 ls_image-key ='Germany'.
 ls_image-value ='deutschland.jpg'.
 APPEND ls_image TO lt_image.
 ls_image-key = 'France'.
 ls_image-value ='france.jpg'.
 APPEND ls_image TO lt_image.
 ls_image-key ='Italy'.
 ls_image-value ='italia.jpg'.
 APPEND ls_image TO lt_image.
 node->bind_table(
 new_items =lt_image
 set_initial_elements = abap_true).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_IMAGE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of an Image UI element.

The implementation of a dynamic Image UI element contains the following statements:

Dynamic creation of an Image UI element

 data lr_image type ref to cl_wd_image.
 data lr_image type ref to cl_wd_image.
 Ir_image = cl_wd_image=>new_image( id =‘IMG_IMAGE’
 bind_width =‘DYNAMIC.WIDTH’
 bind_height =‘DYNAMIC.HEIGHT’
 bind_border =‘DYNAMIC.BORDER’
 bind_source =‘DROPDOWNBYINDEX.VALUE’).

BusinessGraphics

This UI element enables us to use several chart types in our WD application.The Internet Graphics Service (IGS) helps us to work with this UI element,being able to show graphics in a browser.

The chart engine is a C++ library that supports chart types, from simple charts (e.g. bars or pie) to complex charts(e.g. gantt).We create a WD Component with the structure presented in Fig. By using the BusinessGraphics UI element,we show the graphical illustration of the data stored in our database table YPERSON.

WD component structure

Context structure

The node person has the dictionary structure YPERSON, cardinality 1...n, Singleton. From this structure,we choose only LASTNAME and AGE. We have used a chart of columns type,to graphically display the data contained by the columns of our database table.

View Layout

By using the supply function, we populate the node PERSON with data from the database table YPERSON. We select all the data from the two columns LASTNAME and AGE.

Runtime

To perform customizing settings for business graphics, we have to use the SAP Chart Designer. We access this tool by double-clicking on the chart picture, in the view layout. Now,the SAP Chart Designer is open and we can customise our chart.

Chart designer

We save the settings we made; the Framework generates a MIME file in XML format and sets the property customizing of the BusinessGraphics UI element.

Saving the customizing in a XML file

Runtime result

Dynamic Programming

RUNTIME CLASS: CL_WD_BUSINESS_GRAPHICS

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a BusinessGraphics UI element (Table). For a BusinessGra . The Category object has the CL_WD_CATEGORY runtime class.The Series can be Series,runtime
CL_WD_SERIES or SimpleSeries,runtime class CL_WD_SIMPLE_SERIES

The implementation of a dynamic BusinessGraphics UI element(with a SimpleSeries and a Category)contains the following statements.

Dynamic creation of a BusinessGraphics UI element

 METHOD wddomodifyview.
  DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_businessgraphics TYPE REF TO cl_wd_business_graphics.
 DATA lr_category TYPE REF TO cl_wd_category.
 DATA lr_simpleseries TYPE REF TO cl_wd_simple_series.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_businessgraphics = cl_wd_business_graphics=>new_business_graphics(id = 'BGR'
 chart_type = cl_wd_business_graphics=> e_
 chart_type-columns
 dimension = cl_wd_business_graphics=>e_dimension-two
 height = 300
 width = 300
 bind_series_source = 'PERSON'
 customizing = 'D57PJD6VB3MQAZR78XQHWTMIT.xml'
 ).
 lr_flow_data = cl_wd_flow_data=>
 new_flow_data(element = lr_businessgraphics).
 lr_container->add_child(lr_businessgraphics).
 lr_category ?= cl_wd_category=>new_category(id = 'CATEGORY'
 bind_description = 'PERSON.LASTNAME'
 tooltip ='Candidates last name'
 ).
 lr_simpleseries ?=  cl_wd_simple_series=>
 new_simple_series(id ='SIMPLESERIES'
 label ='Candidate Age'
 bind_value ='PERSON.AGE'
 tooltip ='Candidate Age'
 ).
 lr_businessgraphics->set_category(the_category = lr_category).
 lr_businessgraphics->add_series(the_series = lr_simpleseries).
 ENDIF.
 ENDMETHOD.

Action

The UI elements that contain an action are included in this category.Some of these UI elements we have already used (Button, LinkToAction).

Timed Trigger

This UI element triggers automatically and periodically an event.To specify the periodicity,we have to use its delay property. As we have mentioned above, most of the UI element properties can be bound. Hereunder, we show a table with some of the TimedTrigger properties that can be bound and the attribute type in case the property is bindable

Some of TimedTrigger UI element properties


WD component

At every 5 s, we trigger an event that uses a Function Module to generate a random number under 1,000.In context view, we create a node named COUNTER,cardinality 1...1,Singleton that has an attribute COUNTER_TT of i type.

View layout

 

We have used an action named TRIGGER to specify the action to be triggered after the specified delay 5.

 METHOD onactiontrigger.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this->element_counter.
 DATA lv_step TYPE i.
 lr_node = wd_context->get_child_node('COUNTER').
 CALL FUNCTION 'GENERAL_GET_RANDOM_INT'
 EXPORTING
 range = 1000
 IMPORTING
 random = lv_step.
 ls_data-counter_tt = lv_step.
 lr_node->set_static_attributes(ls_data).
 ENDMETHOD.

The Function Module GENERAL_GET_RANDOM_INT has an import parameter named RANGE of i type and an exporting parameter named RANDOM of i type. This function returns the random value with 0(RANDOM)(RANGE) At runtime.

runtime fig

Dynamic Programming

RUNTIME CLASS: CL_WD_TIMED_TRIGGER

As we have seen,by using the wdDoModifyView( )Hook method we can dynamically create an UI element. The same properties, events and aggregations as in the View Designer are available. Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a TimedTrigger UI element .

Dynamic programming

The implementation of a dynamic TimedTrigger UI element contains the following statements.

 DATA lr_timed_trigger TYPE REF TO cl_wd_timed_trigger.
  lr_timed_trigger = cl_wd_timed_trigger=>
 new_timed_trigger(id ='TIMED_TRIGGER'delay = 5 on_action ='TRIGGER').

ButtonChoice

We can use this UI element to choose among the various options offered by the menu. Hereunder, we present a list with some of the ButtonChoice properties that can be bound, and the attribute type in case the property is bindable.

Some of the ButtonChoice UI element properties

We create aWDapplication, where we use the ButtonChoice UI element to offer to the end user a menu list with two options: power and divide. To realise these calculations, we have used the methods of the class CL_FOEV_BUILTINS.As we can see in Fig.this class has many calculation methods,from the PLUS method (that performs a simple addition) to functions,in order to obtain the Integer Part or Hyperbola Sinus.

Class CL_FOEV_BUILTINS

The structure of the POWER method

This method has two importing parameters, named IM_ARG1 and IM_ARG2, and an exporting parameter, named EX_RESULT, of float type. The method DIVIDE has the same parameters.

For this scope, we create our context node named CALCULATE, with the context attributes ARG1 of f type, ARG2 of f type and RESULT of f type, required to perform the calculations and to holdthe result.The WD component structure and the view context structure are presented.

WD component structure and view context structure

The View layout

In the ButtonChoice UI element, we insert two options: menuactionitem1 and menuactionitem2.For the two created options, we set actions(divide and power), and we use the hotkey property to offer to the end user the capability to press the respective key combination to trigger the associated event handler method.

When the user interacts the first time with the ButtonChoice UI element,an action can be selected,and the Framework triggers the proper event handler method. The last selected action remains on the ButtonChoice UI element after the action has been executed. This behaviour is possible through the property repeat SelectedAction.

Some of the ButtonChoice UI element properties

The Framework triggers the event handler method onactiondivide when the user clicks the respective choice option button or he presses the CTRL_D key combination. Listing shows the coding of this method.

 METHOD onactiondivide.
 DATA lr_oref TYPE REF TO cx_foev_error_in_function.
 DATA ls_calculate TYPE wd_this->element_calculate.
 DATA lv_arg1 LIKE ls_calculate-arg1.
 DATA lv_arg2 LIKE ls_calculate-arg2.
 DATA lv_result LIKE ls_calculate-result.
 wd_this->attribute_get(IMPORTING p_arg1 = lv_arg1
 p_arg2 = lv_arg2).
 TRY.
 cl_foev_builtins=>divide(EXPORTING im_arg1 = lv_arg1
 im_arg2 = lv_arg2
 IMPORTING ex_result = lv_result).
 CATCH cx_foev_error_in_function INTO lr_oref.
 ENDTRY.
 wd_this->attribute_set(EXPORTING p_result = lv_result).
 ENDMETHOD.

As we can see, to read the context attributes ATR1 and ATR2, we use the user defined method named ATTRIBUTE_GET that has two exporting parameters.

To pass the result of the division calculation into the context attribute RESULT, we have used the user defined method ATTRIBUTE_SET that has an importing parameter

User defined method required to read the context attributes

User defined method required to populate the RESULT attribute

Runtime for the Divide operation

To rise to power a number (number1 risen to number2), the Framework triggers the event handler method onactionpower (Listing).

 METHOD onactionpower.…………..
 TRY.
 cl_foev_builtins=power(EXPORTING im_arg1 =
 lv_arg1 im_arg2 = lv_arg2   IMPORTING ex_result = lv_result).
 CATCH cx_foev_error_in_function INTO lr_oref.
 ENDTRY.
 ENDMETHOD.

We have used the static method POWER, of the calculation class CL_FOEV_BUILTINS, to perform the number1 risen to number2 operation.To read the context attributes ATR1 and ATR2, we call the same user defined method ATTRIBUTE_ GET; to pass the calculation result, we call the method ATTRIBUTE_SET. In this example, we have caught errors that can occur, but we didn’t display their message to the user. The way we can use try. . . endtry, the way we can raise, catch and display exceptions will be detailed described.

Dynamic Programming

RUNTIME CLASS: CL_WD_BUTTON_CHOICE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a ButtonChoice UI element.

Dynamic programming

The implementation of a dynamic ButtonChoice UI element with one mean action item, named DIVIDE, contains the following statements:

 METHOD wddomodifyview.
 DATA lr_button_choice TYPE REF TO cl_wd_button_choice.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_menu_action TYPE REF TO cl_wd_menu_action_item.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_button_choice = cl_wd_button_choice=>
 new_button_choice( id = 'BTN_CHOICE'
 text = 'Choose'
 repeat_selected_action = abap_false
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_button_choice).
 lr_container->add_child(lr_button_choice).
 lr_menu_action = cl_wd_menu_action_item=>new_menu_action_item
(id ='MENUACTIONITEM1'
 text = 'Divide'
 on_action = 'DIVIDE'
 hotkey = cl_wd_menu_action_item=>e_hotkey-ctrl_p
 ).
 lr_button_choice->add_choice(the_choice = lr_menu_action).
 ENDIF.
 ENDMETHOD.

Selection

This category contains UI elements that have selection options. Hereunder,we present some of the UI Elements included in this category.

Drop Down By Key

This UI element provides the end user with a dropdown list from where he can choose only one entry. We create a WD Component named Y_UI_DROPDOWNBYKEY with a view named V_VIEW and a window.

We have many possibilities to populate with values the dropdown list.For example,we can use a Domain defined in the ABAP Dictionary, we can use the wdDoInit Hook method or a supply function method. For our example, we use Y_COUNTRY_DOMAIN, domain that holds all the names of EU member states.

The View layout is presented in fig

As we have mentioned above, most of the UI element properties can be bound. Hereunder, we present a table with some of the DropDownByKey properties that can be bound, and the attribute type in case the property is bindable.

Some of the DropDownByKey UI element properties

The property selectedKey is mandatory; this means we have to realise data binding at this attribute. The context structure is presented.

Context structure

We have a context node with the cardinality 1. . .1 Singleton that has two attributes. The KEY attribute is of Y_DEFORDOMAIN type,defined in the ABAP Dictionary, and the RESULT attribute is of string type. We define a data binding between the KEY attribute and the selectedKey property of the DropDownByKey.

Data binding

If the selectedKey property of the DropDownByKey UI Element is bound to this attribute,the values stored in the attribute KEY are displayed in the selection list.

We use the attribute RESULT to show, in the textView UI Element,the capital of the first two EU countries,from the dropdown list. After the user chooses a value,the Framework triggers the event handler method onactionselect_country.

the event handler method

 METHOD onactionselect_country.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dropdownbykey.
 DATA lv_value TYPE string.
 lr_node = wd_context-get_child_node('DROPDOWNBYKEY').
 lr_node-get_attribute(EXPORTING name ='KEY'IMPORTING value = lv_value).
 CASE lv_value.
 WHEN 'AT'.
 ls_data-result ='Vienna'.
 WHEN 'BE'.
 ls_data-result ='Brussels'.
 WHEN OTHERS.
 ls_data-result ='Unknown'.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_DROPDOWN_BY_KEY

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a DropDownByKey UI element.

Dynamic programming

The implementation of a dynamic DropDownByKey UI element contains the following statements.

Dynamic creation of a Drop Down By Key UI element

 DATA lr_dropdown_by_key TYPE REF TO cl_wd_dropdown_by_key.
 DATA lv_bind_attribute TYPE string.
 lv_bind_attribute = 'DROPDOWNBYKEY.KEY'.
 lr_dropdown_by_key =cl_wd_dropdown_by_key=
 new_dropdown_by_key(id ='DDK'bind_selected_key =
 lv_bind_attribute text_direction = 
cl_wd_dropdown_by_key=e_text_direction-ltr on_select = 'SELECT_COUNTRY').

Drop Down By Index

This UI element provides the end user with a dropdown list from where he can choose only one entry. This UI element doesn’t differ from the DropDownByKey when displayed on the screen, the implementation being the only difference. We create the same WD Component; in this case, we use a dropDownByIndex UI element instead of the dropDownByKey.In Fig. we show the context structure.In this case, we use a context node with the dictionary structure SHSVALSTR2, cardinality 0...n, Singleton.

Context structure

View Layout

Here under,we present a table with some of the DropDownByIndex properties that can be bound,and the attribute type in case the property is bindable.

Some of DropDownByIndex UI element properties

As we can see,the texts property is mandatory. If this property of the drop- DownByIndex UI Element is bound to the VALUE attribute, the values stored in this attribute are displayed in the selection list. Listing shows how we can populate the dropdown list with values via a supply function method.

Supply function method

 METHOD supply_dropdownbyindex.
 DATA:
 ls_country TYPE if_v_view=element_dropdownbyindex,
 lt_country LIKE TABLE OF ls_country.
 ls_country-value ='Austria'.
 ls_country-key ='Vienna'.
 APPEND ls_country TO lt_country.
 ls_country-value ='Belgium'.
 ls_country-key ='Brussels'.
 APPEND ls_country TO lt_country.
 node-bind_table(new_items = lt_country set_initial_elements = abap_true).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_DROPDOWN_BY_IDX

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a DropDownByIndex UI element.

Dynamic programming

The implementation of a dynamic DropDownByIndex UI element

 DATA lr_dropdown_by_index TYPE REF TO cl_wd_dropdown_by_idx.
 DATA lv_bind_attribute TYPE string.
 lv_bind_attribute ='DROPDOWNBYINDEX.VALUE'.
 lr_dropdown_by_index = cl_wd_dropdown_by_idx=new_dropdown_by_idx
(id = 'DDI'bind_texts = lv_bind_attribute text_direction = cl_wd.

Radio Button Group By Index

This UI Element includes some RadioButtons,allowing the user to select only one value. Similar to the DropDown lists,we have here RadioButtons grouped by key and by index. Indifferent of the type,they don’t differ when they are displayed on the screen,but only in the implementation part.

We create the same WD Component as for the DropDownByIndex UI element;in this case,we change the DropDownByIndex UI element withthe RadioButton- GroupByIndex.The view context has the same structure. We create a context node named RADIOBUTTONGROUP_I with the dictionary structure SHSVALSTR2, cardinality 0. . .n, Singleton.

Hereunder, we present a table with some of the RadioButtonGroupByIndex properties that can be bound, and the attribute type in case the property is bindable.

Some of the RadioButtonGroupByIndex UI element properties

View Layout

We define the same data binding between the VALUE attribute and the texts property of the RadioButtonGroupByIndex. If this property of the RadioButton- GroupByIndex UI Element is bound to the VALUE attribute, the values stored in this attribute are displayed in columns and rows.

To specify the number of columns in which the RadioButtonGroup elements are grouped, we can use the property colCount. In our case, we have set “2”.This property can be personalised by an administrator.Listing  shows how we can populate the RadioButtons with values via a supply function method (the same method as for the DropDownByIndex lists).

Supply function method

 METHOD supply_radiobutton_i.
 DATA:
 ls_country TYPE wd_this-element_radiobuttongroup_i,
 lt_country LIKE TABLE OF ls_country.
 ls_country-value = 'Austria'.
 ls_country-key = 'Vienna'.
 APPEND ls_country TO lt_country.
 ls_country-value = 'Belgium'.
 ls_country-key = 'Brussels'.
 APPEND ls_country TO lt_country.
 node-bind_table( new_items = lt_country set_initial_elements = abap_true).
 ENDMETHOD.

Runtime

For the RadioButtonGroupByKey UI element, we have the same concept as described for the DropDownByKey.

Dynamic Programming

RUNTIME CLASS: CL_WD_RADIOBUTTON_GROUP_BY_IDX

Hereunder, we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a RadioButtonGroupByIndex UI element.

Dynamic programming

The implementation of a dynamic RadioButtonGroupByIndex UI element contains the following statements:

Dynamic creation of a RadioButtonGroupByIndex UI element

 DATA lr_radiobutton_group_by_index TYPE REF TO
 cl_wd_radiobutton_group_by_idx.
 DATA lv_bind_attribute TYPE string.
 lv_bind_attribute ='RADIOBUTTONGROUP_I.VALUE'.
 lr_radiobutton_group_by_index =
 cl_wd_radiobutton_group_by_idx=>new_radiobutton_group_by_idx(
 id = 'RDB_INDEX'
 bind_texts = lv_bind_attribute
 col_count = 2
 on_select = 'SHOW’).

Layout

This category has UI elements we use to form the layout. Hereunder,we present some of the UI Elements included in this category.

ViewContainerUIElement

This UI element is an area within a view that contains another view. It doesn’t have its own properties,but inherits properties from the abstract base class UIElement. We create a WD Component,a registration form with three views.In the view V_VIEW,we insert two ViewContainerUIElement’s (VCU_1 and VCU_2) required to embed the V_STEP1 and V_STEP2 views. The context node is created in COMPONENTCONTROLLER because we have to share data among different view controllers: V_STEP1, V_STEP2, V_VIEW.

WD component structure

Context structure

The node INFO has the cardinality 0...1, Singleton. The attributes NAME, EMAIL, CITY are of STRING type, and the attribute COUNTRY is of Y_DEFORDOMAIN type defined in the ABAP Dictionary, domain that holds all the EU member states.

At runtime, the view V_VIEW is the default view (e.g. the view that is first displayed when the window is called).

View V_VIEW layout

Because we want to display more views in the same time and in the same window,we are going to use ViewContainerUIElement. At runtime,when the screen is displayed for the first time, we want only the fields from V_VIEW view to be visible until the user presses the LinkToAction UI Element. This is the reason why we embed as default in VCU_1 and VCU_2 EMPTYVIEWs.An EMPTYVIEW is a special type of view, automatically generated, that can be used to hide another view.

Window structure

Runtime

As we can see, only the UI Elements from the default view V_VIEW are displayed, because the VCU_1 and VCU_2 have EMPTYVIEWs as default.

Embedding Views in Window

After the user presses the LinkToAction UI element, we want to show in the VCU_1 the view V_STEP1. To be able to do this, we define an outbound plug in the V_VIEW view.

Definition of an outbound plug in the view V_VIEW

 

V_STEP1 view layout

To be able to show the view V_STEP1 content when the user presses the LinkToAction UI Element, we have to define an inbound plug in the view V_STEP1.

Definition of an Inbound Plug in the view V_STEP1

Now,we embed the view V_STEP1 in the ViewContainerUIElement VCU_1 and we create the navigation link.

Window structure

When the user presses the LinkToAction UI element, the Framework triggers the event handler method onactionlta1. When we create an outbound plug for a view,a fire method is added to its interface. A fire method of our outbound plug op_to_v_ step1 is called with the statement:

wd_this!fire_op_to_v_step1_plg( ).

We have created a navigation link from OP_TO_V_STEP1 to IP_V_STEP1. When this method is fired, the view V_STEP1 is displayed. To integrate the fire method, we can use the Web Dynpro Code Wizard.

Calling the web Dynpro code wizard

Runtime

Hereunder,we have to display the view V_STEP2 when the user presses the LinkToAction UI element (ID = LTA_NEXT2). To do this, we define an outbound plug named OP_TO_V_STEP2 in the view V_STEP1,and we fire the generated method.

Outbound plug, event handler method

V_STEP2 view layout

After this, we have to define an inbound plug named IP_V_STEP2, we embed the view V_STEP2 into the ViewContainerUIElement VCU_2 and we create the corresponding navigation link.

Window structure

Window structure

Dynamic Programming

RUNTIME CLASS: CL_WD_VIEW_CONTAINER_UIELEMENT

The implementation of a dynamic ViewContainerUIElement contains the following statements (Listing):

data lr_vcu type ref to cl_wd_view_container_uielement.
lr_vcu = cl_wd_view_container_uielement=>new_view_container_uielement (id = 'VCU').

In this case, after dynamically creating the View ContainerUI Element,we have to dynamically create the view embedding and the navigation links.

tabStrip

This UI element allows us to display some tabs, and the user can toggle from a tab page to another. We create a WD Component.

WD component structure

We create a TabStrip UI element and add two Tabs. To add tabs, we right-click on the tabStrip name and, from the contextual menu, we choose Insert Tab.When the user presses the Next button, we navigate to the next tab and we show the data entered by the user in the registration form of the first tab.

View layout

Hereunder, we present a table with some of the tabStrip UI element properties that can be bound,and the attribute type in case the property is bindable.

Some of TabStrip UI element properties

The property selectedTab of string type can be used to navigate from a tab to other one. This property set the name of the selected tab. We define a data binding between the selectedTab property and the attribute with the same name (string) defined in the node DYNAMIC in the view context.The node STUDENT has the dictionary structure YSTR_PERSON,cardinality 0...1,Singleton. 

Context structure

By using the wdDoInit Hook method, we populate the attribute SELECTEDTAB of the node DYNAMIC with the ID of the tab we want to be active at runtime–TAB_1 (Listing ).

Listing The wddoinit Hook method

 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-selectedtab = 'TAB_1'.
lr_node-set_static_attributes(ls_data).
ENDMETHOD.

When the user presses the Next Button,the Framework triggers the event handler method onactionnext (Listing).We set the selectedtab property with the value TAB_2,by selecting in this mode the TAB_2.

Listing Event handler methodMETHOD onactionnext.

 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-selectedtab = 'TAB_2'.
lr_node-set_static_attributes(ls_data).
ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TABSTRIP

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a TabStrip UI element.For the tabStrip UI element we have, as aggregation, the Tab element.Its runtime class is CL_WD_TAB.

Dynamic programming

The implementation of a dynamic TabStrip UI element, with two Tabs,contains the following statements (Listing):

Dynamic programming of a TabStrip UI element

 METHOD wddomodifyview.
DATAlr_pageheader TYPE REF TO cl_wd_page_header.
DATAlr_flow_data TYPE REF TO cl_wd_flow_data.
DATAlr_container TYPE REF TO cl_wd_uielement_container.
DATAlr_area TYPE REF TO cl_wd_page_header_area.
IF first_time EQ abap_true.
lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
lr_pageheader = cl_wd_page_header=>new_page_header(id = 'PH_PAGEHEADER' text_direction = cl_wd_page_header=>e_text_direction-ltr ). lr_pageheader->set_title('DYNAMIC PAGEHEADER'). lr_flow_data = cl_wd_flow_data=>new_flow_data(element = lr_pageheader). lr_container->add_child(lr_pageheader). lr_area = cl_wd_page_header_area=>new_page_header_area(id ='PAGEHEADAREA' design = cl_wd_page_header_area=>e_design-emphasized). DATA lr_textview TYPE REF TO cl_wd_text_view. lr_textview = cl_wd_text_view=>new_text_view(id = 'TXT' text ='PageHeaderArea' ). lr_area->set_content(the_content = lr_textview ). lr_pageheader->add_area(the_area = lr_area ). ENDIF. ENDMETHOD.

PageHeader

This UI element offers the possibility to create a header for a page.In the title content and the PageHeader Area, we can insert other UI elements. We create a WD component with the structure presented in Fig.

WD component structure

We use the view V_VIEW as Master View. Here, we insert a PageHeader UI element that contains two LinkToAction UI elements, and in the PageHeader Area we insert a ViewContainerUIElement. When the user interacts with the LinkToAction UI elements,we show in the ViewContainerUIElement one of the two slave views V_COUNTRYor V_CANDIDATE.

Application structure

After the PageHeader UI element is inserted into the V_VIEW view,we can insert a PageHeader Title Content and one or more PageHeader Area(s).

Inserting the title content and PageHeader area

In a PageHeaderArea, we can insert how many other UI elements we want.Here, we have chosen to insert only one UI element (ViewContainerUIELement).As design options,it has: Standard, Emphasized and transparent.For our example,we have the default design: Standard. To see on screen the other Page Header Area designs,we can choose values from the list, one by one, and see the result in the view designer, or we can run again the application and see the different changes.In the system,we can find two WD components where we can see the UI elements and the effect of changing certain properties on these UI elements. These components are WDR_TEST_EVENTS and WDR_TEST_UI_ELEMENTS. 

V_VIEW view layout

Each view (V_CANDIDATE and V_COUNTRY) has a Table UI element where we show the data stored in our database table YPERSON and YEU_COUNTRIES.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_PAGE_HEADER

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a PageHeader UI element.

Dynamic programming

For the PageHeader UI element we have, as aggregation, the Area and the TitleContent elements. The Area runtime class is CL_WD_PAGE_HEADER_ AREA.

The implementation of a dynamic PageHeader UI element (with pageHeader title) and a PageHeaderArea (with a textView UI element) contains the following statements (Listing):

Dynamic programming of a PageHeader UI element

 METHOD wddomodifyview.
DATA lr_pageheader TYPE REF TO cl_wd_page_header.
DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
DATA lr_container TYPE REF TO cl_wd_uielement_container.
DATA lr_area TYPE REF TO cl_wd_page_header_area.
IF first_time EQ abap_true.
lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
lr_pageheader = cl_wd_page_header=>new_page_header(
id = 'PH_PAGEHEADER'
text_direction = cl_wd_page_header=>e_text_direction-ltr
).
lr_pageheader->set_title('DYNAMIC PAGEHEADER').
lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
lr_pageheader).
lr_container->add_child(lr_pageheader).
lr_area = cl_wd_page_header_area=>new_page_header_area(
id = 'PAGEHEADAREA'
design = cl_wd_page_header_area=>e_design-emphasized
).
DATA lr_textview TYPE REF TO cl_wd_text_view.
lr_textview = cl_wd_text_view=>new_text_view(
id = 'TXT'
text = 'PageHeaderArea'
). lr_area->set_content(the_content = lr_textview).
lr_pageheader->add_area(the_area = lr_area).
ENDIF.
ENDMETHOD.

ContextualPanel

This UI element offers navigation functions. Its navigation list can have many levels.We create the same example as for the PageHeader,but, in this case,we use the two LinkTo Action UIElements to create the content for a ContextualPanel UI element.

In a contextualPanel UI element, we can insert three types of elements: Free- ContextualArea,NavigationList and ViewSwitch. In our example,we have used two FreeContextualArea elements.

In a FreeContextualArea, we can insert a Content and a Header. We can set the header to be expandable or no. The Content is a zone where we can insert other UI elements we want to be displayed within the FreeContextualArea.

FreeContexualArea

V_VIEW view Layout

V_VIEW view Layout

Dynamic Programming

RUNTIME CLASS: CL_WD_CONTEXTUAL_PANEL

For the ContextualPanel UI element, we have, as aggregation, the items: Free- ContextualArea,
ViewSwitch and NavigationList elements.
The FreeContextual- Area runtime class is
CL_WD_FREE_CONTEXTUAL_AREA.

The implementation of a dynamic contextualPanel UI element,with a Free- ContextualArea element that has a Content(linkToAction UI element)and a Header(expandableTitle element),contains the following statements (Listing ):

Dynamic programming of a contextualPanel UI element

 METHOD wddomodifyview.
DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
DATA lr_container TYPE REF TO cl_wd_uielement_container.
DATA lr_contextualpanel TYPE REF TO cl_wd_contextual_panel.
DATA lr_freecontextualarea TYPE REF TO cl_wd_free_contextual_area.
DATA lr_linktoaction TYPE REF TO cl_wd_link_to_action.
DATA lr_header TYPE REF TO cl_wd_expandable_title.
IF first_time EQ abap_true.
lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
lr_contextualpanel = cl_wd_contextual_panel=&g new_contextual_panel(
id = 'CP_CONTEXTUALPANEL'
).
lr_freecontextualarea = cl_wd_free_contextual_area=>new_free_contextual_ar
ea(
id = 'FREECONTEXTUALAREA_1'
).
lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
lr_contextualpanel).
lr_container->add_child(lr_contextualpanel).
lr_linktoaction = cl_wd_link_to_action=>new_link_to_action(
id = 'CONTENT_1'
on_action ='SHOW_COUNTRIES'
text ='Show EU countries'
).
lr_freecontextualarea->set_content(the_content = lr_linktoaction).
lr_header = cl_wd_expandable_title=>new_expandable_title(
id ='EXPANDABLETITLE_1'
expandable = abap_true
expanded = abap_true
title ='COUNTRY'
).
lr_freecontextualarea->set_header(the_header = lr_header).
lr_contextualpanel->add_item(the_item = lr_freecontextualarea).
ENDIF.

Tray UI Element

As all the containers, this UI element includes a set of other UI Elements,but also provides additional functions. We create a WD Component with the structure presented.

WD component structure

In the View Layout,we insert two Tray UI elements. The first element is used to show the candidate information, and the second Tray is used to show some details about the selected candidate. These details are: the country flag and the capital.In the MIMEs folder we import three pictures with the flags we have to display when the user chooses a competitor from that country.

After the Tray UI element is inserted in the View Layout, we can insert a Menu and, in each menu, we can insert a menu option.

Tray menu

The menu options are: Menu, MenuActionItem,MenuCheckBox, MenuRadio- Button and MenuSeparator. In our case,we have chosen the option MenuAction- Item.

Creating a menu element

View layout structure

The first Tray has two menu options, used to show the second Tray UI element or to hide it. As we have mentioned above, most of the UI element properties can be bound. Hereunder, we show a list with some of the Tray UI elements properties that can be bound, and the attribute type in case the property is bindable.

Some of the tray UI element properties

We want to manipulate the UI element via the data held in the context. Therefore, we create a context node named DYNAMIC, with three attributes: two attributes of WDY_BOOLEAN type (ENABLED_OPTION1,ENABLED_OPTION2) and one attribute named VISIBLE, of WDUI_VISIBILITY type.To show the concurrent information and the corresponding details, we have created a context node with the dictionary structure YVIEW_CMPETITION, a database view defined in the ABAP Dictionary.

Context structure.

The context node DETAIL is populated via the supply function method SUPPLY_COMPETITION (Listing).

Supply function method

 METHOD supply_competition.
DATA: lt_content TYPE TABLE OF yview_cmpetition.
SELECT * FROM yview_cmpetition INTO TABLE lt_content. IF sy-subrc = 0.
node->bind_table(new_items = lt_content).
ENDIF.
ENDMETHOD.

To be able to manipulate the enabled properties of the menu options created in the first Tray UI elements, we define the following data binding:

Data binding

To be able to manipulate the visible property of the second Tray with the ID “TRAY_DETAIL”,we define a data binding between these properties and the context attribute VISIBLE:

At initialisation, we want the second Tray to be hidden, the MENU_OPTION1 to be enabled and the MENU_OPTION2 to be not enabled. To realise this,we encode the wdDoInit Hook method (Listing).

The wddoinit Hook method

 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-enabled_option1 = abap_true.
ls_data-enabled_option2 = abap_false.
ls_data-visible = cl_wd_tray=e_visible-none.
lr_node-set_static_attributes( ls_data ).
ENDMETHOD.

When the user selects the first menu option “MENU_OPTION1”,the Framework triggers the event handler method onactionshow (Listing ).

The onactionshow event handler method

 METHOD onactionshow.
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-enabled_option1 = abap_false.
ls_data-enabled_option2 = abap_true.
ls_data-visible = cl_wd_tray=e_visible-visible.
lr_node-set_static_attributes(ls_data).
ENDMETHOD.

When the user selects the second menu option MENListingU_OPTION2,the Framework triggers the event handler method onactionhide (Listing).

The onactionhide event handler method

 METHOD onactionhide.
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-enabled_option1 = abap_true.
ls_data-enabled_option2 = abap_false.
ls_data-visible = cl_wd_tray=e_visible-none.
lr_node->set_static_attributes(ls_data).
ENDMETHOD.

At runtime,we can choose to show or to hide the details about the competitor

Runtime.

Message Area

This UI element represents the placeholder of the messages; it helps us to specify where they appear in the view. As we have seen, the messages are displayed by default in the upper part of the screen. The message location can be moved by adding a MessageArea UI element. We need only a MessageArea UI element per View layout.

We create an example to filter an input from the end user. In case the user enters a combination of small and capital letters from A to Z or spaces,we show a message with the text “Your input is string” If not, we show a message “Your input is not string”. To show these messages,we use a MessageArea UI element.

There are small programs used to test the regexes, which offer the possibility to test the regexes created before using them. Such a program is demo_ regex_toy. By using the transaction SA38 or SE38, we can run this program (Fig.) By using regexes,we can filter the values that the user enters in a Web Dynpro screen.

Regex toy screen

View Layout

As we can see, in this case we have entered a MessageArea UI element in the Group container.This is the place where all the messages will be displayed. When the user presses the button with the id “BTN”,the Framework triggers the event handler method onactioncheck (Listing ).

Checking the data entered by the user methode

As we can see, in this case we have entered a MessageArea UI element in the Group container.This is the place where all the messages will be displayed. When the user presses the button with the id “BTN”,the Framework triggers the event handler method onactioncheck (Listing ).

Checking the data entered by the user methode

 METHOD onactioncheck.
DATA: lv_firstname TYPE string,
lv_pattern TYPE string.
wd_context->get_attribute(EXPORTING name ='FIRSTNAME'
IMPORTING value = lv_firstname).
v_pattern ='[a-zA-Zs]*'.
CHECK lv_firstname IS NOT INITIAL.
DATA: lr_api_controller TYPE REF TO if_wd_controller,
lr_message_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( ).
DATA: lt_message_parameters TYPE wdr_name_value_list,
ls_message_parameter LIKE LINE OF lt_message_parameters.
ls_message_parameter-name = 'first_name'.
ls_message_parameter-value = lv_firstname.
APPEND ls_message_parameter TO lt_message_parameters.
F cl_abap_matcher=>matches(pattern = lv_pattern
text = lv_firstname) = abap_true. lr_message_manager-> report_message(message_text ='Your input &first_name is string'
message_type = 0
params = lt_message_parameters).
ELSE.
lr_message_manager-> report_message(message_text ='Your input &first_name is not string!'
message_type = 2
params = lt_message_parameters).
endif.
ENDMETHOD.

By using the static method MATCHES of the CL_ABAP_MATCHER class,we check the value that the user enters in the inputField UI element.In case this value matches our condition specified in the local variable lv_pattern,we use the methode REPORT_MESSAGE to display a message of information type. Otherwise,we use the same method to display an error message. Because we want to show to the user whether the value he entered in the input field is a string or not,we use a parameter required to integrate,in the string that he sees on the screen,the value he has just entered.For this purpose, we have used for the method report_message a parameter named “params”.By double-clicking on name of the method report_message,we navigate forward and we can see all the parameters that this method has and the typethat the parameters should be. For the “parms” parameter, we need a variable owdr_name_value_list type that is actually a table type with a structure of line type.From this structure, we have used the name(the parameter name,in our case “first_name”)and the value (the value with what we want to replace,at runtime,the parameter name “lv_firstname”).In Chap. 10, we will see more abou the message manager and parameters, along with the modality we can display a message into a window, or the modality we can use the ABAP classesto create messages and exceptions. In Fig.the messages are displayed by using the MesageArea UI element.

Runtime with MessageArea UI element

Dynamic Programming

RUNTIME CLASS: CL_WD_MESSAGE_AREA

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a MessageArea UI element (Table).

The implementation of a dynamic MessageArea UI element contains the following statements (Listing ):

Dynamic programming

The dynamic programming of a MessageArea UI element

 data lr_messagearea type ref to cl_wd_message_area.
lr_messagearea = cl_wd_message_area=>new_message_area(
id ='MESSAGE_AREA'
HISTORY_VISIBLE = abap_true).

Complex

This category contains complex UI elements as regards their structure and content.Hereunder,we present some of the UI Elements included in this category.

Table

By using this UI element, we can display data arranged in rows and columns.Table shows some of the Table properties that can be bound,and the attribute type in case the property is bindable.

Some of the Table UI element properties

In this exercise,we want to take data from an end user and to insert them into a table UI element,after the latest record. To do this,we create a WD component named Y_UI_TABLE that has a View named V_VIEW and a default window.In the context view,we need two context nodes: a context node required to hold the new record from the end user and a context node required to hold all the records.

Context structure

The context node REGISTRATION has the cardinality 1. . .1, Singleton.Its attributes are: NAME of STRING type,DATE OF BIRTH of YDATEOFBIRTH type,COUNTRY of Y_DEFORDOMAIN type and NO of I type. We use the attributes of this context node to hold every new record.

The context node TABLE has the cardinality 0...n,Singleton, selection 0...1, supply function SUPPLY_PERSON and initialization lead selection is not automatically set. In this case,we want to manually set the lead selection. The context node attributes have the same name and data type as the context node REGISTRATION.We use the attributes of this context node to hold all the registrations.

In the next step,we have to create the view layout.To insert a Table into our view layout,we can use two options: we can manually insert the table or we can use the Web Dynpro Wizard. In the beginning, we explain the first option. After inserting a Table UI element into our view,we have to create a data binding.When a table is bound to a context node by using a wizard,we don’tneed to individually create each table column. We have only to select the context node and the Framework provides the available attributes.In this way,the value of the property DataSource (mandatory) of the Table UI element is bound to the context node TABLE.

Table UI element – Creating the binding

The Cell Editors of the Table Column describe the UI element used to display or edit the column content.As we can see,our columns are created by using textView UI elements. Each attribute represents a column in our table, and for each column we can choose an UI element. After this, the standard property to be bound depends on the chosen UI element.For example, for the TextView UI element, the property is text, and for the DropDownByKey, the name of the property to be bound is selectedKey.

Cell Editor of Table Column – Name of Property to be bound

The view layout is presented in Fig. For each attribute for which the bind option is marked, the Framework generates a proper column. For example, for the attribute “NO”,the Framework has generated the column TBL_EXAMPLE_NO, for the attribute NAME, the Framework has generated the column TBL_EXAPLE_NAME,etc.The Table UI element offers the possibility to display as many rows as we need by using the property visibleRowCount (in our case, five). In the default mode,the property displayEmptyRows is set as ABAP_TRUE. In case we set this property as ABAP_FALSE, the rows that are empty in our table will not be on screen anymore.

The second option to insert a Table UI element into our View Layout is to use the Web Dynpro Wizard (Fig). In this case,the Wizard generates the Table UI element and we use the same procedure presented hereunder to create the data binding. After the user enters the new values (Name, Date of Birth and Country),we have to add these values at the end of the other records, in the table UI element. To be able to do this, we need an action. Fig Cell Editor of Table Column – Name of Property to be bounding.

After the user enters the new values (Name, Date of Birth and Country),we have to add these values at the end of the other records,in the table UI element. To be able to do this, we need an action.

View layout

Web Dynpro wizard to insert a Table UI element into the view layout

For a table UI element, we can insert a Toolbar. We need a toolbar to be able to insert a ToolBarButton in this area. We populate the node TABLE with two values, via the supply function method.

The local variable lv_counter is used to create the record ID. After the node population, we use the SET_LEAD_SELECTION_INDEX method to set lead selection via index. As we can see, the index is set with the value of the lv_counter. In this way,it is selected the last value of the table.

Inserting a ToolBarButton

Supply function method

 METHOD supply_person.
 DATA:
 ls_table TYPE wd_this-element_table,
 lt_table LIKE TABLE OF ls_table,
 lv_counter TYPE i VALUE 1.
 ls_table-no = lv_counter.
 ls_table-name = 'Antonia Maria Crist'.
 ls_table-dateofbirth = '19800305'.
 ls_table-country = 'DE'.
 lv_counter = lv_counter + 1.
 APPEND ls_table TO lt_table.
 ls_table-no = lv_counter.
 ls_table-name = 'Albu Alina'.
 ls_table-dateofbirth = '19800908'.
 ls_table-country = 'IT'.
 APPEND ls_table TO lt_table.
 node->bind_table(new_items=lt_table set_initial_elements = abap_true).
 node-set_lead_selection_index(index=lv_counter).
 ENDMETHOD.

As we have mentioned above, if the “Initialization lead selection” for a node is “YES”, it is always selected the first element of this node. In this case, our context node has this property selected “NO”; we influence the selected element by using the set_lead_selection_index.

To influence the lead selection, we have some methods, as following

  • Set_lead_selectio
  • Move_first
  • Move_previous
  • Move_

For our TABLE context node, we have set the selection cardinality 0...1 meaning that maximum one row can be selected if the node elements are displayed as a table. When the user presses the “Add record” button,the Framework triggers the event handler method onactionadd.

Event handler method

 METHOD onactionadd.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 lr_node1 TYPE REF TO if_wd_context_node,
 lr_element TYPE REF TO if_wd_context_element,
 lv_counter TYPE i,
 lv_dateofbirth TYPE ydateofbirth,
 lv_country TYPE y_defordomain,
 lv_name TYPE string,
 ls_registration TYPE wd_this->element_registration.
 lr_node = wd_context->get_child_node('REGISTRATION').
 lr_node->get_attribute(EXPORTING name ='DATEOFBIRTH'
 IMPORTING value = lv_dateofbirth).
 lr_node->get_attribute(EXPORTING name ='NAME'
 IMPORTING value = lv_name).
 lr_node->get_attribute(EXPORTING name ='COUNTRY'
 IMPORTING value = lv_country).
 lr_node1 = wd_context->get_child_node('TABLE').
 lr_node1->get_attribute(EXPORTING name ='NO'
 IMPORTING value = lv_counter).
 lv_counter = lv_counter + 1.
 ls_registration-no = lv_counter.
 ls_registration-dateofbirth = lv_dateofbirth.
 ls_registration-name = lv_name.
 ls_registration-country = lv_country.
 lr_node->set_static_attributes(ls_registration).
 lr_element = lr_node->get_lead_selection( ).
 lr_element->
 get_static_attributes( IMPORTING static_attributes = ls_registration ).
 lr_node1 = wd_context->get_child_node('TABLE').
 lr_node1->bind_structure( EXPORTING new_item = ls_registration
 set_initial_elements = abap_false).
 lr_node1->set_lead_selection_index(index = lv_counter).
 ENDMETHOD.

We pass the value of the attribute NO of the TABLE context node in the local variable lv_counter. As we have mentioned above,we use this local variable to create the record ID.After each new record,we increase this value with 1.The user enters the values Name,Date of Birth and Country and we create his corresponding ID.The runtime structure is presented.

Runtime

Additionally,we can add a reset Button on the table toolbar. After the user adds the records, he can reset the fields Name, Date of birth and Country, to be able to add a new record. The “Reset” Toolbar Button,of the same ToolBarButton type, has associated an action named RESET. The Listing shows the onactionreset event handler method.

The onactionreset event handler method

 METHOD onactionreset.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 ls_registration TYPE wd_this-element_registration.
 lr_node = wd_context-get_child_node('REGISTRATION').
 lr_node->bind_structure(EXPORTING new_item = ls_registration).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TABLE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a Table UI element.

Dynamic programming

For the Table UI element,we have, as aggregation, the Table Column,Group Column, Header,Legend Popin, MasterColumn and Toolbar. The TableColumn element represents a column of a table, and has the CL_WD_TABLE_COLUMN runtime class. The table title is implemented by using a Caption element and has the CL_WD_CAPTION runtime class.

The implementation of a dynamic Table UI element with table header,design alternating, three visible rows and a column, that has a TextView UI element as cell editor,contains the following statements.

Dynamic programming of a Table UI element

 METHOD wddomodifyview.
 DATA lr_table TYPE REF TO cl_wd_table.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_column_name TYPE REF TO cl_wd_table_column.
 DATA lr_text_view TYPE REF TO cl_wd_text_view.
 DATA lr_table_header TYPE REF TO cl_wd_caption.
 DATA lr_column_name_header TYPE REF TO cl_wd_caption.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_table = cl_wd_table=>new_table(
 id ='TBL_TABLE'
 bind_data_source ='TABLE'
 design = cl_wd_table=>e_design-alternating
 visible_row_count = 3
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_table ).
 lr_container->add_child(lr_table).
 lr_column_name = cl_wd_table_column=>new_table_column(
 id = 'TBL_EXAMPLE_NAME'
 ).
 lr_table_header ?= cl_wd_caption=>new_caption(text ='Table UI elem
 ent - example').
 lr_table->add_column(the_column = lr_column_name).
 lr_table->set_header(lr_table_header).
 lr_text_view = cl_wd_text_view=>new_text_view(
 id ='TXV_NAME'
 bind_text ='TABLE.NAME'
 ).
 lr_column_name_header ?= cl_wd_caption=>new_caption(text = 'Nam
 e').
 lr_column_name->
 set_table_cell_editor(the_table_cell_editor = lr_text_view
 ).
 lr_column_name->set_header(lr_column_name_header).
 ENDIF.
 ENDMETHOD.

RoadMap

By using this UI element, we can display the steps required to complete a certain task. Hereunder,we show some of the roadMap properties that can be bound,and the attribute type in case the property is bindable.

For the RoadMap example,we use the exercise from the ViewContainerUIElement,a little bit re-arranged. The WD component structure is presented.

WD component structure

In this case,we replace the LinkToAction UI elements with two Buttons: Next and Back. These Buttons are inserted into the view V_VIEW, and the user can navigate from the first step to the end one, via the RoadMap. In this case, we used only a ViewContainerUIElement,and for each step we have a view. In the view V_VIEW, we insert a RoadMap UI element with three steps. To insert a step into a RoadMap UI Element, we right-click on the element and, from the contextual menu, we choose Insert Step.

RoadMap steps

V_VIEW view layout

T0 be able to manipulate the RoadMap UI element and the Button via the data held in the context, we create, in the V_VIEW, a context node named DYNAMIC. This node has three attributes:

  • SELECTEDSTEP, of STRING type, used to dynamically set the ID of the selected step
  • ENABLED_NEXT, of WDY_BOOLEAN type, used to manipulate the enabled property of the NEXT button
  • ENABLED_BACK,of WDY_BOOLEAN type,used to manipulate the enabled property of the BACK button (Fig – right)

To hold and show the data entered by the user, we have created, in the COM PONENTCONTROLLER context, a node named INFO (Fig. – left).This context node has the same structure as presented in the ViewContainerUIElement example. The attributes are: NAME, EMAIL & CITY (of STRING type) and COUNTRY (of Y_DEFORDOMAIN type). We create a context mapping among this context node and the context views V_STEP1, V_STEP2 and V_STEP3.

Context structure

V_STEP1 view layout

V_STEP2 view layout

V_STEP3 view layout

The view “V_VIEW” is the default view – the firstly displayed one.In the ViewContainerUIElement,we embed all the three views V_STEP1,V_STEP2 and V_STEP3. The view V_STEP1 is, in this case, the default view. To be able to navigate among the views, we have to create inbound and outbound plugs. In the view V_VIEW, we create three outbound plugs:

  • OP_TO_V_STEP1 required to navigate to the view V_STEP1
  • OP_TO_V_STEP2 required to navigate to the view V_STEP2
  • OP_TO_V_STEP3 required to navigate to the view V_STEP3

The view V_STEP1 has an inbound plug named IP_V_STEP1,the view V_STEP2 has an inbound plug named IP_V_STEP2 and the view V_STEP3 has an inbound plug named IP_V_STEP3.

Window structure

In the wdDoInit Hook method (V_VIEW),we dynamically set the attributes values for SELECTEDSTEP, ENABLED_NEXT and ENABLED_BACK.

The wdDoInit Hook method

 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-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 ls_data-selectedstep ='STEP1'.
 lr_node->set_static_attributes(ls_data).
 ENDMETHOD.

First time when the screen is rendered, we want the BACK Button to be not enabled,the NEXT Button to be enabled, and the STEP1 to be the active RoadMap step.

Runtime

When the user presses the NEXT button, the Framework triggers the event handler method onactionnext.

The onactionnext event handler method

 METHOD onactionnext.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 DATA lv_selectedstep TYPE string.
 lr_node = wd_context-get_child_node('DYNAMIC').
 lr_node-get_attribute
 (EXPORTING name ='SELECTED STEP'IMPORTING value = lv_selectedstep ).
 ASE lv_selectedstep.
 WHEN ‘STEP1’.
 ls_data-selectedstep = ‘STEP2’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step2_plg( ).
 WHEN ‘STEP2’.
 ls_data-selectedstep = ‘STEP3’.
 ls_data-enabled_next = abap_false.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step3_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_false.
 ls_data-enabled_back = abap_true.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

As we can see, we make active the STEP2: ls_data-selectedstep = ‘STEP2’,we fire the method that helps us to navigate to the nextview V_STEP2

wd_thisfire_op_to_v_step2_plg( )
and we enable both buttons
ls_data-enabled_next = abap_true.
ls_data-enabled_back = abap_true.

Runtime

When the user presses again the NEXT button,we deactivate the NEXT button ls_data-enabled_next = abap_false we make active STEP3 ls_data-selectedstep = ‘STEP3’and fire the method that helps us to navigate to the view V_STEP3 wd_this!fire_op_to_v_step3_plg( ),

Runtime

When the user presses the BACK button, the Framework triggers the event handler method onactionback.

The onactionback event handler method

 METHOD onactionback.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 DATA lv_selectedstep TYPE string.
 lr_node = wd_context-get_child_node(‘DYNAMIC’).
 lr_node-get_attribute
( EXPORTING name =‘SELECTEDSTEP’IMPORTING value = lv_selectedstep).
 CASE lv_selectedstep.
 WHEN ‘STEP3’.
 ls_data-selectedstep = ‘STEP2’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step2_plg( ).
 WHEN ‘STEP2’.
 ls_data-selectedstep = ‘STEP1’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 wd_this->fire_op_to_v_step1_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 NDCASE.
 r_node-set_static_attributes(ls_data ).
  ENDMETHOD.

As we can see(Fig.)when the user presses the BACK button,we navigate back to the view V_STEP2

wd_this!fire_op_to_v_step2_plg( ).
we activate both buttons ls_data-enabled_next = abap_true.
ls_data-enabled_back = abap_true.
we make active the step STEP2 ls_data-selectedstep = ‘STEP2’.
wd_this!fire_op_to_v_step2_plg( ).

Runtime

When the user presses again the BACK Button (Fig.),we navigate back to the view V_STEP1

wd_this!fire_op_to_v_step1_plg( ).
we deactivate the BACK button ls_data-enabled_back = abap_false.
and make active the step STEP1 ls_data-selectedstep = ‘STEP1’.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_ROAD_MAP

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a RoadMap UI element.

Dynamic programming

For the RoadMap UI element,we have, as aggregation, the Step: Road Map Step or MultipleRoadMapStep.The RoadMapStep element represents a step in a Road- Map,and has the CL_WD_ROAD_MAP_STEP runtime class.

The implementation of a dynamic RoadMap UI element with two Steps contains the following statements:

Dynamic programming of a RoadMap UI element

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_roadmap TYPE REF TO cl_wd_road_map.
 DATA lr_step1 TYPE REF TO cl_wd_road_map_step.
 DATA lr_step2 TYPE REF TO cl_wd_road_map_step.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_roadmap = cl_wd_road_map=>new_road_map(
 id = 'RM_ROADMAP'
 bind_selected_step ='DYNAMIC.SELECTEDSTEP'
 start_point_design = cl_wd_road_map=>e_start_point_design-selected
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_roadmap).
 lr_container->add_child(lr_roadmap).
lr_step1 = cl_wd_road_map_step=>new_road_map_step(
 id = 'STEP1'
 description ='STEP 1'
 name ='1'
 ).
 lr_roadmap->add_step(the_step = lr_step1).
 lr_step2 = cl_wd_road_map_step=>new_road_map_st
 id = 'STEP2'
 description ='STEP 2'
 name ='2'
 ).
 lr_roadmap->add_step(he_step = lr_step2).
 ENDIF.
 ENDMETHOD.

PhaseIndicator

Similar to the Road Map UI element, we can display then the steps in a wizard,by using the PhaseIndicator. Hereunder,we show some of the PhaseIndicator properties that can be bound, and the attribute type in case the property is bindable.

Some of the PhaseIndicator UI element properties

A Phase is a step into a PhaseIndicator that has bindable properties as,for example,enable and status. Table presents some of these properties and how we can use the status property for a dynamic manipulation.

Some of the phase properties and the dynamic manipulation of the status

We create the same example as for the RoadMap, but,in this case,we use a PhaseIndicator UI element with three phases.The WD component structure is presented.

WD component structure

In this case,we have renamed the views V_STEP1, V_STEP2 and V_STEP3 as V_PHASE1,V_PHASE2 and V_PHASE3. The content of these views is the same.We can rename a view by right-clicking on the view name and, from the contextual menu,we choose rename. To insert a phase into a PhaseIndicator UI Element, we right-clickon the element and,from the contextual menu, we choose Insert Phase.

Inserting Phase into a PhaseIndicator

For the first Phase,we have set the status property: completed. For the other two Phases(Phase2 and Phase3),we have dynamically set the status property,by using the two attributes named STATUS2 and STATUS3 of WDUI_PHASE_STATUS type.To manipulate the enabled property of the NEXT button, we use the same attribute ENABLED_NEXT of WDY_BOOLEAN type, and to manipulate the selected phase, we use the attribute SELECTEDPHASE of string type (Fig right).

The node INFO is defined in the COMPONENTCONTROLLER and has the same structure as showed in the previous example. We create context mapping among this context node and the context views V_PHASE1,V_PHASE2 and V_PHASE3.

Context structure

The V_VIEW layout

This view has two outbound plugs defined: OP_TO_V_PHASE2 and OP_TO_V_PHASE3.The view V_PHASE1 has no inbound plug, the view V_PHASE2 has an inbound plug named IP_V_PHASE2 and the view PHASE_3 has an inbound plug named IP_V_PHASE3. The window structure is presented.

Window structure

The view V_PHASE1 is shown in the ViewControllerUIElement first time when the screen is rendered, this view being defined as default view.We have to dynamically set the attributes values for SELECTEDPHASE,STATS2,STATUS3 and ENABLED_NEXT. To do this, we use the wdDoInit Hook method.

The wdDoInit Hook method

 METHOD wddoinit.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE if_v_view=element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-enabled_next = abap_true.
 ls_data-status2 = CL_WD_PHASE=E_STATUS-WARNING.
 ls_data-status3 = CL_WD_PHASE=E_STATUS-WARNING.
 ls_data-selectedphase = 'PHASE1'.
 lr_node-set_static_attributes(ls_data).
ENDMETHOD.

As we can see,we selected the first phase: ls_data-selectedphase = ‘PHASE1’and we set the Phase2 and Phase3 with the Warning status ls_data-status2 = cl_wd_phase) e_status-warning.
ls_data-status3 = cl_wd_phase) e_status-warning.

Runtime

When the user presses the button, the Framework triggers the event handler method onactionnext.

The onactionnext event handler method

 METHOD onactionnext.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE if_v_view=element_dynamic.
 DATA lv_phase TYPE string.
 lr_node = wd_context->get_child_node('DYNAMIC').
 lr_node-get_attribute
(EXPORTING name ='SELECTEDPHASE'IMPORTING value = lv_phase).
 CASE lv_phase.
 WHEN 'PHASE1'.
 ls_data-selected phase ='PHASE2'.
 ls_data-enabled_next = abap_true.
 ls_data-status2 = cl_wd_phase=e_status-completed.
 ls_data-status3 = cl_wd_phase=e_status-warning.
 wd_this-fire_op_to_v_phase2_plg( ).
 WHEN 'PHASE2'.
 ls_data-selectedphase = 'PHASE3'.
 ls_data-enabled_next = abap_false.
 ls_data-status2 = cl_wd_phase=e_status-completed.
 ls_data-status3 = cl_wd_phase=e_status-completed.
 wd_this-fire_op_to_v_phase3_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_false.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

As we can see, we make active the Phase2 ls_data-selectedphase ¼ ‘PHASE2’ we set the Phase2 with completed status and Phase3 with warning status ls_data-status2 cl_wd_phase )
e_status-completed.ls_data-status3 = cl_wd_phase)e_status-warning.

For the next press of the NEXT button,we set the Phase2 and Phase3 with completed status

ls_data-status2 cl_wd_phase)e_status-completed.
ls_data-status3 cl_wd_phase)e_status-completed.we make active the last Phase, ls_data-selectedphase = ‘PHASE3’.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_PHASE_INDICATOR

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a PhaseIndicator UI element

Dynamic programming

For the PhaseIndicator UI element,we have,as aggregation, the Phase element. It has the CL_WD_PHASE runtime class.
The implementation of a dynamic PhaseIndicator UI element with two Phases contains the following statements:

Dynamic programming of a PhaseIndicator UI element

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_phaseindicator TYPE REF TO cl_wd_phase_indicator.
 DATA lr_phase1 TYPE REF TO cl_wd_phase.
 DATA lr_phase2 TYPE REF TO cl_wd_phase.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_phaseindicator = cl_wd_phase_indicator=>new_phase_indicator(
 id = 'PI_PHASEINDICATOR'
 bind_selected_phase ='DYNAMIC.SELECTEDPHASE'
 irst_visible_phase ='PHASE1'
 background_design = cl_wd_phase_indicator=>
 e_background_designtransparent
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_phaseindicator).
 lr_container->add_child(lr_phaseindicator).
 lr_phase1 = cl_wd_phase=>new_phase(
 id ='PHASE1'
 description ='PHASE 1'
 status = cl_wd_phase=>e_status-completed
 ).
 lr_phaseindicator->add_phase(the_phase = lr_phase1).
 lr_phase2 = cl_wd_phase=>new_phase(
 ld ='PHASE2'
 description ='PHASE 2'
 bind_status ='DYNAMIC.STATUS2'
 ).
 lr_phaseindicator->add_phase(the_phase = lr_phase2).
 ENDIF.
 ENDMETHOD.

Tree - Sequential Implementation

With this UI element,we can visualise the hierarchy defined in the context. For this UI element,we can use:

  • A sequential implementation with a non-recursive node in case the number of levels can be specified at design time
  • A recursive implementation with a recursive node in case the number of levels is not known at design time

WD component

In this case(sequential implementation,we don’t need a recursive node. A context node TREE is created in the context node of the view controller. It has the cardinality 1...1 and is Singleton.Under this context node,we create another context node TREE_NODE with two attributes. Under this context node,we create another context node TREE_LEAF with an attribute.

Context structure

The attributes STUDENTNAME, VALUE and STUDENTINFO are of STRING type.The context node TREE_LEAF is not Singleton,because we need to create an instance of this node for each element of the TREE_NODE context node.In the STUDENTNAME attribute, we hold the name of each student; for each student we have proper information held in the attribute STUDENTINFO. In a Tree UI element, we can insert Node Types of type TreeItemType and TreeNodeType,to specify which subnodes and which context attributes are going to be displayed.

Inserting Node Type

View layout

Binding of the Context to the Tree elements

The context node TREE_NODE is populated via the supply function method.

TREE_NODE context node

 METHOD supply_tree_node.
 DATA:
 ls_studentTYPE if_v_view
 =element_tree_node,lt_student LIKE TABLE OF ls_student.
 ls_student-studentname = 'Ionescu Ana Maria'.
 ls_student-value = 'A'.
 APPEND ls_student TO lt_student.
 ls_student-studentname = 'Marinescu Loredana'.
 ls_student-value = 'B'.
 APPEND ls_student TO lt_student.
 ls_student-studentname = 'Marton Luminita'.
 ls_student-value = 'C'.
 APPEND ls_student TO lt_student.
 node-bind_table(lt_student ).
 ENDMETHOD.

The values for the child node TREE_LEAF are set in the same way via a supply function method.

Populating the attributes of the TREE_LEAF context node

 METHOD supply_tree_leaf.
 DATA:
 ls_studentTYPE if_v_view=>
 element_tree_leaf,lt_student LIKE TABLE OF ls_student.
 DATA: lv_value TYPE string.
 parent_element->get_attribute
 (EXPORTING name = 'VALUE'IMPORTING value = lv_value ).
 CASE lv_value.
 WHEN 'A'.
 ls_student-student info ='Article - YES'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo = 'Exam - 5'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo = 'Academic year -II'.
 APPEND ls_student TO lt_student.
 WHEN 'B'.
 ls_student-studentinfo ='Article - NO'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Academic year -I'.
 APPEND ls_student TO lt_student.
 WHEN OTHERS.
 ls_student-studentinfo ='Article - YES'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Exam - 3'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Academic year -IV'.
 APPEND ls_student TO lt_student.
 ENDCASE.
 node-bind_table(lt_student).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TREE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a Tree UI element.

Dynamic programming

For the Tree UI element, we have, as aggregation, the Node Types: TreeItem-Type and TreeNodeType. The TreeItemType element has the CL_WD_TREE_ ITEM_TYPE runtime class and the TreeNodeType element has the CL_WD_TREE_NODE_TYPE runtime class.

The implementation of a dynamic Tree UI element with two node types (Tree- NodeType and TreeItemType)contains the following statements:

Dynamic programming

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_tree TYPE REF TO cl_wd_tree.
 DATA lr_treenode TYPE REF TO cl_wd_tree_node_type.
 DATA lr_treeitem TYPE REF TO cl_wd_tree_item_type.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_tree = cl_wd_tree=>new_tree(
 id = 'TRE_SEQUENTIAL'
 bind_data_source = 'TREE'
 title = 'Student info'
 default_node_icon_source = '~Icon/CheckedOk'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_tree).
 lr_container->add_child(lr_tree).
 lr_treenode = cl_wd_tree_node_type=>new_tree_node_type(
 id ='TREE_NT'
 bind_data_source ='TREE.TREE_NODE'
 bind_text ='TREE.TREE_NODE.STUDENTNAME'
 ).
 lr_treeitem = cl_wd_tree_item_type=>new_tree_item_type(
 id ='TREE_IT'
 bind_data_source ='TREE.TREE_NODE.TREE_LEAF'
 bind_text ='TREE.TREE_NODE.TREE_LEAF.STUDENTINFO'
 ).
 lr_tree->add_node_type(index = 1
 the_node_type = lr_treenode).
 lr_tree->add_node_type(index = 2
 the_node_type = lr_treeitem).
 ENDIF.
 ENDMETHOD.

DateNavigator

This UI element offers the possibilities to display and navigate in a calendar and to enter dates, by choosing a year, a month,a day or a range of dates,from the showed calendar.

Hereunder,we present a table with some of the DataNavigator properties that can be bound, and the attribute type in case the property is bindable.

Some of the DataNavigator UI element properties

We create a WD Component named Y_UI_DATENAVIGATOR. In the context view,we create three attributes: MONTH, WEEK and DAY of STRING type,and two context nodes:

  • LEGEND,Cardinality 0. . .n, supply function named SUPPLY_LEGEND,attributes:
    CATEGORY of WDY_MD_DATE_MARKING_CATEGORY type and TEXT of STRING type
  • MARKING,Cardinality 0...n,supply function named SUPPLY_MARKING, attributes: CATEGORY of WDY_MD_DATE_MARKING_CATEGORY type and DATE of D type.

In the view layout,we insert a DateNavigator UI element with a DateNavigator- Legend and DateNavigatorMarking. By using the DateNavigatorLegend element,we can add a legend for the DateNavigator, and with the DateNavigator- Marking element,we can highlight entries of a specific category within the Date- Navigator UI element.

Context view and DateNavigatorLegend, DateNavigatorMarking properties

The most important properties of the DateNavigatorLegend element are:

  • “Category”,which allows us to create the legend categories (in format one,two,three and four).It shall be bound to a context attribute that stores these categories.
  • “Text”, which stores the texts, describing each category.
  • “DataSource”,which shall be bound to a context node,which stores the categories and the texts of the legend entries. The most important properties of the DateNavigatorMarking element are:
  • “Category”,which shall be bound to a context attribute that stores the category of the highlighted data.
  • “DataSource”,which shall be bound to a context node which stores the categories,data and tooltip of the highlighted data.
  • “Tooltip” is not necessarily bindable. In our case,we have not created an attribute for the tooltip,because we don’t want to display a quick info text when the user passes the mouse pointer over the highlighted data of the Date- Navigator UI element.
  • “Data” shall be bound to a context attribute that stores the date of the highlighted data.

View layout

The DateNavigator UI element has many properties and events. In our case,we have changed the properties:

 

In this way,we have chosen Sunday as the first day of the week in our calendar.

In this way,we show 3 months in our calendar.

We have chosen from the list the range option,because we want to offer the possibility to select the range of dates.

We have set the starting date of our calendar.

To be able to show,in the TextView UI elements,the week,the day or the month that the end-user selects in our calendar,we have used the events:onDaySelect,on Month Select and on Week Select.

Events of the DataNavigator UI element

First of all,we have to populate our nodes with values. The Listing shows the SUPPLY_LEGEND supply function method.

The SUPPLY_LEGEND supply function method

 METHOD supply_legend.
 DATA: 
 ls_legend TYPE wd_this-element_legend,lt_legend LIKE TABLE OF ls_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-one.
 ls_legend-text = 'Doors open day'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=>e_category-two.
 ls_legend-text = 'Operating teams trip'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=>e_category-three.
 ls_legend-text = 'Happy hour'.
 INSERT ls_legend INTO TABLE lt_legend.
 node-bind_table( lt_legend ).
 ENDMETHOD.

We create three legend categories(one, two and three),with the texts:“Doors open day” for the first category, “Operating teams trip”for the second category and “Happy hour” for the third category.

The Listing shows the SUPPLY_MARKING supply function method required to populate with values the MARKING node.

The SUPPLY_MARKING supply function method

 METHOD supply_legend.
 DATA:
 ls_legend TYPE wd_this-element_legend,lt_legend LIKE TABLE OF ls_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-one.
 ls_legend-text = 'Doors open day'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-two.
 ls_legend-text = 'Operating teams trip'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-three.
 ls_legend-text = 'Happy hour'.
 INSERT ls_legend INTO TABLE lt_legend.
 node-bind_table( lt_legend ).
 ENDMETHOD.

In this way we mark (highlight),for the first category,the day 11.08.2009,for the second category,the day 21.08.2009,and for the third category,the day 24.08.2009. When the user selects a day in our calendar,the Framework triggers the event handler method onactionon_day_select.

The onactionon_day_select event handler method

As import parameter, for our event handler method, we have the parameter named DAY of D type that holds the selected day. We pass this value in our DAY attribute created in the context view.

When the user selects a Week in our calendar, the Framework triggers the event handler method onactionon_week_select.

The onactionon_week_select event handler method

As import parameter,for our event handler method,we have the parameters: WEEK of I type that holds the selected week and YEAR of I type that holds the corresponding year of the selected week. We pass these values in our WEEK attribute created in the context view.

When the user selects a Month in our calendar,the Framework triggers the event handler method onactionon_month_select. The onactionon_month_select event handler method. As import parameters,for our event handler method,we have: MONTH of I type that holds the selected month and YEAR of I type that holds the corresponding of the selected month. We pass these values in our MONTH attribute created in context view.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_DATE_NAVIGATOR

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a DateNavigation UI element.

Dynamic programming

The implementation of a dynamic DateNavigator UI element with elements: DateNavigatorLegent and DateNavigatorMarking, contains the following statements:

Dynamic programming of a DataNavigator UI element

 METHOD wddomodifyview.
 DATA lr_date_navigator TYPE REF TO cl_wd_date_navigator.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_datenav_legend TYPE REF TO cl_wd_date_nav_legend.
 DATA lr_datenav_marking TYPE REF TO cl_wd_date_nav_marking.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_date_navigator = cl_wd_date_navigator=>new_date_navigator(
 id ='DATENAVIGATOR'
 first_day_of_week = cl_wd_date_navigator=>e_first_day_of_week-sunday
 months_per_column = 1
 months_per_row = 3
 selection_mode = cl_wd_date_navigator=>e_selection_mode-range
 starts_with ='20090801'
 on_day_select ='ON_DAY_SELECT'
 on_month_select ='ON_MONTH_SELECT'
 on_week_select ='ON_WEEK_SELECT'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_date_navigator).
 lr_container->add_child(lr_date_navigator).
 lr_datenav_legend = cl_wd_date_nav_legend=>new_date_nav_legend(
 id ='DATENAVIGATORLEGEND'
 bind_category ='LEGEND.CATEGORY'
 bind_data_source ='LEGEND'
 bind_text ='LEGEND.TEXT'
 ).
 lr_date_navigator->set_legend(the_legend = lr_datenav_legend).
 lr_datenav_marking = cl_wd_date_nav_marking=>new_date_nav_marking(
 id = 'DATENAVIGATORMARKING'
 bind_category = MARKING.CATEGORY'
 bind_data_source ='MARKING'
 bind_date ='MARKING.DATE'
 ).
 lr_date_navigator->set_marking(the_marking=lr_datenav_marking) 
 ENDIF.
 ENDMETHOD.

Integration

This category contains complex UI elements as regards their structure and content.Hereunder,we present some of the UI Elements included in this category.

Table

By using this UI element, we can display data arranged in rows and columns.Table shows some of the Table properties that can be bound,and the attribute type in case the property is bindable.

Some of the Table UI element properties

In this exercise,we want to take data from an end user and to insert them into a table UI element,after the latest record. To do this,we create a WD component named Y_UI_TABLE that has a View named V_VIEW and a default window.In the context view,we need two context nodes: a context node required to hold the new record from the end user and a context node required to hold all the records.

Context structure

The context node REGISTRATION has the cardinality 1. . .1, Singleton.Its attributes are: NAME of STRING type,DATE OF BIRTH of YDATEOFBIRTH type,COUNTRY of Y_DEFORDOMAIN type and NO of I type. We use the attributes of this context node to hold every new record.

The context node TABLE has the cardinality 0...n,Singleton, selection 0...1, supply function SUPPLY_PERSON and initialization lead selection is not automatically set. In this case,we want to manually set the lead selection. The context node attributes have the same name and data type as the context node REGISTRATION.We use the attributes of this context node to hold all the registrations.

In the next step,we have to create the view layout.To insert a Table into our view layout,we can use two options: we can manually insert the table or we can use the Web Dynpro Wizard. In the beginning, we explain the first option. After inserting a Table UI element into our view,we have to create a data binding.When a table is bound to a context node by using a wizard,we don’tneed to individually create each table column. We have only to select the context node and the Framework provides the available attributes.In this way,the value of the property DataSource (mandatory) of the Table UI element is bound to the context node TABLE.

Table UI element – Creating the binding

The Cell Editors of the Table Column describe the UI element used to display or edit the column content.As we can see,our columns are created by using textView UI elements. Each attribute represents a column in our table, and for each column we can choose an UI element. After this, the standard property to be bound depends on the chosen UI element.For example, for the TextView UI element, the property is text, and for the DropDownByKey, the name of the property to be bound is selectedKey.

Cell Editor of Table Column – Name of Property to be bound

The view layout is presented in Fig. For each attribute for which the bind option is marked, the Framework generates a proper column. For example, for the attribute “NO”,the Framework has generated the column TBL_EXAMPLE_NO, for the attribute NAME, the Framework has generated the column TBL_EXAPLE_NAME,etc.The Table UI element offers the possibility to display as many rows as we need by using the property visibleRowCount (in our case, five). In the default mode,the property displayEmptyRows is set as ABAP_TRUE. In case we set this property as ABAP_FALSE, the rows that are empty in our table will not be on screen anymore.

The second option to insert a Table UI element into our View Layout is to use the Web Dynpro Wizard (Fig). In this case,the Wizard generates the Table UI element and we use the same procedure presented hereunder to create the data binding. After the user enters the new values (Name, Date of Birth and Country),we have to add these values at the end of the other records, in the table UI element. To be able to do this, we need an action. Fig Cell Editor of Table Column – Name of Property to be bounding.

After the user enters the new values (Name, Date of Birth and Country),we have to add these values at the end of the other records,in the table UI element. To be able to do this, we need an action.

View layout

Web Dynpro wizard to insert a Table UI element into the view layout

For a table UI element, we can insert a Toolbar. We need a toolbar to be able to insert a ToolBarButton in this area. We populate the node TABLE with two values, via the supply function method.

The local variable lv_counter is used to create the record ID. After the node population, we use the SET_LEAD_SELECTION_INDEX method to set lead selection via index. As we can see, the index is set with the value of the lv_counter. In this way,it is selected the last value of the table.

Inserting a ToolBarButton

Supply function method

 METHOD supply_person.
 DATA:
 ls_table TYPE wd_this-element_table,
 lt_table LIKE TABLE OF ls_table,
 lv_counter TYPE i VALUE 1.
 ls_table-no = lv_counter.
 ls_table-name = 'Antonia Maria Crist'.
 ls_table-dateofbirth = '19800305'.
 ls_table-country = 'DE'.
 lv_counter = lv_counter + 1.
 APPEND ls_table TO lt_table.
 ls_table-no = lv_counter.
 ls_table-name = 'Albu Alina'.
 ls_table-dateofbirth = '19800908'.
 ls_table-country = 'IT'.
 APPEND ls_table TO lt_table.
 node->bind_table(new_items=lt_table set_initial_elements = abap_true).
 node-set_lead_selection_index(index=lv_counter).
 ENDMETHOD.

As we have mentioned above, if the “Initialization lead selection” for a node is “YES”, it is always selected the first element of this node. In this case, our context node has this property selected “NO”; we influence the selected element by using the set_lead_selection_index.

To influence the lead selection, we have some methods, as following

  • Set_lead_selectio
  • Move_first
  • Move_previous
  • Move_

For our TABLE context node, we have set the selection cardinality 0...1 meaning that maximum one row can be selected if the node elements are displayed as a table.

When the user presses the “Add record” button,the Framework triggers the event handler method onactionadd.

Event handler method

 METHOD onactionadd.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 lr_node1 TYPE REF TO if_wd_context_node,
 lr_element TYPE REF TO if_wd_context_element,
 lv_counter TYPE i,
 lv_dateofbirth TYPE ydateofbirth,
 lv_country TYPE y_defordomain,
 lv_name TYPE string,
 ls_registration TYPE wd_this->element_registration.
 lr_node = wd_context->get_child_node('REGISTRATION').
 lr_node->get_attribute(EXPORTING name ='DATEOFBIRTH'
 IMPORTING value = lv_dateofbirth).
 lr_node->get_attribute(EXPORTING name ='NAME'
 IMPORTING value = lv_name).
 lr_node->get_attribute(EXPORTING name ='COUNTRY'
 IMPORTING value = lv_country).
 lr_node1 = wd_context->get_child_node('TABLE').
 lr_node1->get_attribute(EXPORTING name ='NO'
 IMPORTING value = lv_counter).
 lv_counter = lv_counter + 1.
 ls_registration-no = lv_counter.
 ls_registration-dateofbirth = lv_dateofbirth.
 ls_registration-name = lv_name.
 ls_registration-country = lv_country.
 lr_node->set_static_attributes(ls_registration).
 lr_element = lr_node->get_lead_selection( ).
 lr_element->
 get_static_attributes( IMPORTING static_attributes = ls_registration ).
 lr_node1 = wd_context->get_child_node('TABLE').
 lr_node1->bind_structure( EXPORTING new_item = ls_registration
 set_initial_elements = abap_false).
 lr_node1->set_lead_selection_index(index = lv_counter).
 ENDMETHOD.

We pass the value of the attribute NO of the TABLE context node in the local variable lv_counter. As we have mentioned above,we use this local variable to create the record ID.After each new record,we increase this value with 1.The user enters the values Name,Date of Birth and Country and we create his corresponding ID.The runtime structure is presented.

Runtime

Additionally,we can add a reset Button on the table toolbar. After the user adds the records, he can reset the fields Name, Date of birth and Country, to be able to add a new record. The “Reset” Toolbar Button,of the same ToolBarButton type, has associated an action named RESET. The Listing shows the onactionreset event handler method.

The onactionreset event handler method

 METHOD onactionreset.
 DATA: lr_node TYPE REF TO if_wd_context_node,
 ls_registration TYPE wd_this-element_registration.
 lr_node = wd_context-get_child_node('REGISTRATION').
 lr_node->bind_structure(EXPORTING new_item = ls_registration).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TABLE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a Table UI element.

Dynamic programming

For the Table UI element,we have, as aggregation, the Table Column,Group Column, Header,Legend Popin, MasterColumn and Toolbar. The TableColumn element represents a column of a table, and has the CL_WD_TABLE_COLUMN runtime class. The table title is implemented by using a Caption element and has the CL_WD_CAPTION runtime class.

The implementation of a dynamic Table UI element with table header,design alternating, three visible rows and a column, that has a TextView UI element as cell editor,contains the following statements.

Dynamic programming of a Table UI element

 METHOD wddomodifyview.
 DATA lr_table TYPE REF TO cl_wd_table.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_column_name TYPE REF TO cl_wd_table_column.
 DATA lr_text_view TYPE REF TO cl_wd_text_view.
 DATA lr_table_header TYPE REF TO cl_wd_caption.
 DATA lr_column_name_header TYPE REF TO cl_wd_caption.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_table = cl_wd_table=>new_table(
 id ='TBL_TABLE'
 bind_data_source ='TABLE'
 design = cl_wd_table=>e_design-alternating
 visible_row_count = 3
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_table ).
 lr_container->add_child(lr_table).
 lr_column_name = cl_wd_table_column=>new_table_column(
 id = 'TBL_EXAMPLE_NAME'
 ).
 lr_table_header ?= cl_wd_caption=>new_caption(text ='Table UI elem
 ent - example').
 lr_table->add_column(the_column = lr_column_name).
 lr_table->set_header(lr_table_header).
 lr_text_view = cl_wd_text_view=>new_text_view(
 id ='TXV_NAME'
 bind_text ='TABLE.NAME'
 ).
 lr_column_name_header ?= cl_wd_caption=>new_caption(text = 'Nam
 e').
 lr_column_name->
 set_table_cell_editor(the_table_cell_editor = lr_text_view
 ).
 lr_column_name->set_header(lr_column_name_header).
 ENDIF.
 ENDMETHOD.

RoadMap

By using this UI element, we can display the steps required to complete a certain task. Hereunder,we show some of the roadMap properties that can be bound,and the attribute type in case the property is bindable.

Some of the Table UI element properties

For the RoadMap example,we use the exercise from the ViewContainerUIElement,a little bit re-arranged. The WD component structure is presented.

WD component structure

In this case,we replace the LinkToAction UI elements with two Buttons: Next and Back. These Buttons are inserted into the view V_VIEW, and the user can navigate from the first step to the end one, via the RoadMap. In this case, we used only a View ContainerUIElement,and for each step we have a view. In the view V_VIEW, we insert a RoadMap UI element with three steps. To insert a step into a RoadMap UI Element, we right-click on the element and, from the contextual menu, we choose Insert Step.

RoadMap steps

V_VIEW view layout

T0 be able to manipulate the RoadMap UI element and the Button via the data held in the context, we create, in the V_VIEW, a context node named DYNAMIC. This node has three attributes:

  • SELECTEDSTEP, of STRING type, used to dynamically set the ID of the selected step
  • ENABLED_NEXT, of WDY_BOOLEAN type, used to manipulate the enabled property of the NEXT button
  • ENABLED_BACK,of WDY_BOOLEAN type,used to manipulate the enabled property of the BACK button (Fig – right)

To hold and show the data entered by the user, we have created, in the COM PONENTCONTROLLER context, a node named INFO (Fig. – left).This context node has the same structure as presented in the ViewContainerUIElement example. The attributes are: NAME, EMAIL & CITY (of STRING type) and COUNTRY (of Y_DEFORDOMAIN type). We create a context mapping among this context node and the context views V_STEP1, V_STEP2 and V_STEP3.

Context structure

V_STEP1 view layout

V_STEP2 view layout

V_STEP3 view layout

The view “V_VIEW” is the default view – the firstly displayed one.In the ViewContainerUIElement,we embed all the three views V_STEP1,V_STEP2 and V_STEP3. The view V_STEP1 is, in this case, the default view.

To be able to navigate among the views, we have to create inbound and outbound plugs. In the view V_VIEW, we create three outbound plugs:

  • OP_TO_V_STEP1 required to navigate to the view V_STEP1
  • OP_TO_V_STEP2 required to navigate to the view V_STEP2
  • OP_TO_V_STEP3 required to navigate to the view V_STEP3

The view V_STEP1 has an inbound plug named IP_V_STEP1,the view V_STEP2 has an inbound plug named IP_V_STEP2 and the view V_STEP3 has an inbound plug named IP_V_STEP3.

Window structure

In the wdDoInit Hook method (V_VIEW),we dynamically set the attributes values for SELECTEDSTEP, ENABLED_NEXT and ENABLED_BACK.

The wdDoInit Hook method

 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-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 ls_data-selectedstep ='STEP1'.
 lr_node->set_static_attributes(ls_data).
 ENDMETHOD.

First time when the screen is rendered, we want the BACK Button to be not enabled,the NEXT Button to be enabled, and the STEP1 to be the active RoadMap step.

Runtime

When the user presses the NEXT button, the Framework triggers the event handler method onactionnext.

The onactionnext event handler method

 METHOD onactionnext.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 DATA lv_selectedstep TYPE string.
 lr_node = wd_context-get_child_node('DYNAMIC').
 lr_node-get_attribute(EXPORTING name =
'SELECTED STEP'IMPORTING value = lv_selectedstep ).
 ASE lv_selectedstep.
 WHEN ‘STEP1’.
 ls_data-selectedstep = ‘STEP2’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step2_plg( ).
 WHEN ‘STEP2’.
 ls_data-selectedstep = ‘STEP3’.
 ls_data-enabled_next = abap_false.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step3_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_false.
 ls_data-enabled_back = abap_true.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

As we can see, we make active the STEP2: ls_data-selectedstep = ‘STEP2’,we fire the method that helps us to navigate to the nextview V_STEP2

wd_thisfire_op_to_v_step2_plg( )
and we enable both buttons
ls_data-enabled_next = abap_true.
ls_data-enabled_back = abap_true.

Runtime

When the user presses again the NEXT button,we deactivate the NEXT button ls_data-enabled_next = abap_false we make active STEP3 ls_data-selectedstep = ‘STEP3’and fire the method that helps us to navigate to the view V_STEP3 wd_this!fire_op_to_v_step3_plg( ),

Runtime

When the user presses the BACK button, the Framework triggers the event handler method onactionback.

The onactionback event handler method

 METHOD onactionback.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE wd_this-element_dynamic.
 DATA lv_selectedstep TYPE string.
 lr_node = wd_context-get_child_node(‘DYNAMIC’).
 lr_node-get_attribute( EXPORTING name =‘SELECTEDSTEP’IMPORTING value = lv_selectedstep).
 CASE lv_selectedstep.
 WHEN ‘STEP3’.
 ls_data-selectedstep = ‘STEP2’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_true.
 wd_this-fire_op_to_v_step2_plg( ).
 WHEN ‘STEP2’.
 ls_data-selectedstep = ‘STEP1’.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 wd_this->fire_op_to_v_step1_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_true.
 ls_data-enabled_back = abap_false.
 NDCASE.
 r_node-set_static_attributes(ls_data ).
  ENDMETHOD.

As we can see(Fig.)when the user presses the BACK button,we navigate back to the view V_STEP2

wd_this!fire_op_to_v_step2_plg( ).
we activate both buttons ls_data-enabled_next = abap_true.
ls_data-enabled_back = abap_true.
we make active the step STEP2 ls_data-selectedstep = ‘STEP2’.
wd_this!fire_op_to_v_step2_plg( ).

Runtime

When the user presses again the BACK Button (Fig.),we navigate back to the view V_STEP1

wd_this!fire_op_to_v_step1_plg( ).
we deactivate the BACK button ls_data-enabled_back = abap_false.
and make active the step STEP1 ls_data-selectedstep = ‘STEP1’.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_ROAD_MAP

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a RoadMap UI element.

Dynamic programming

For the RoadMap UI element,we have, as aggregation, the Step: Road Map Step or MultipleRoadMapStep.The RoadMapStep element represents a step in a Road- Map,and has the CL_WD_ROAD_MAP_STEP runtime class.

The implementation of a dynamic RoadMap UI element with two Steps contains the following statements:

Dynamic programming of a RoadMap UI element

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_roadmap TYPE REF TO cl_wd_road_map.
 DATA lr_step1 TYPE REF TO cl_wd_road_map_step.
 DATA lr_step2 TYPE REF TO cl_wd_road_map_step.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_roadmap = cl_wd_road_map=>new_road_map(
 id = 'RM_ROADMAP'
 bind_selected_step ='DYNAMIC.SELECTEDSTEP'
 start_point_design = cl_wd_road_map=>e_start_point_design-selected
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_roadmap).
 lr_container->add_child(lr_roadmap).
 lr_step1 = cl_wd_road_map_step=>new_road_map_step(
 id = 'STEP1'
 description ='STEP 1'
 name ='1'
 ).
 lr_roadmap->add_step(the_step = lr_step1).
 lr_step2 = cl_wd_road_map_step=>new_road_map_st
 id = 'STEP2'
 description ='STEP 2'
 name ='2'
 ).
 lr_roadmap->add_step(he_step = lr_step2).
 ENDIF.
 ENDMETHOD.

PhaseIndicator

Similar to the Road Map UI element, we can display then the steps in a wizard,by using the PhaseIndicator. Hereunder,we show some of the PhaseIndicator properties that can be bound, and the attribute type in case the property is bindable.

Some of the PhaseIndicator UI element properties


A Phase is a step into a PhaseIndicator that has bindable properties as,for example,enable and status. Table presents some of these properties and how we can use the status property for a dynamic manipulation.

Some of the phase properties and the dynamic manipulation of the status

We create the same example as for the RoadMap, but,in this case,we use a PhaseIndicator UI element with three phases.The WD component structure is presented.

WD component structure

In this case,we have renamed the views V_STEP1, V_STEP2 and V_STEP3 as V_PHASE1,V_PHASE2 and V_PHASE3. The content of these views is the same.We can rename a view by right-clicking on the view name and, from the contextual menu,we choose rename. To insert a phase into a PhaseIndicator UI Element, we right-clickon the element and,from the contextual menu, we choose Insert Phase.

Inserting Phase into a PhaseIndicator

For the first Phase,we have set the status property: completed. For the other two Phases(Phase2 and Phase3),we have dynamically set the status property,by using the two attributes named STATUS2 and STATUS3 of WDUI_PHASE_STATUS type.To manipulate the enabled property of the NEXT button, we use the same attribute ENABLED_NEXT of WDY_BOOLEAN type, and to manipulate the selected phase, we use the attribute SELECTEDPHASE of string type (Fig right).

The node INFO is defined in the COMPONENTCONTROLLER and has the same structure as showed in the previous example. We create context mapping among this context node and the context views V_PHASE1,V_PHASE2 and V_PHASE3.

Context structure

The V_VIEW layout

This view has two outbound plugs defined: OP_TO_V_PHASE2 and OP_TO_V_PHASE3.The view V_PHASE1 has no inbound plug, the view V_PHASE2 has an inbound plug named IP_V_PHASE2 and the view PHASE_3 has an inbound plug named IP_V_PHASE3. The window structure is presented.

Window structure

The view V_PHASE1 is shown in the ViewControllerUIElement first time when the screen is rendered, this view being defined as default view.We have to dynamically set the attributes values for SELECTEDPHASE,STATS2,STATUS3 and ENABLED_NEXT. To do this, we use the wdDoInit Hook method.

The wdDoInit Hook method

 METHOD wddoinit.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE if_v_view=element_dynamic.
 lr_node = wd_context-get_child_node('DYNAMIC').
 ls_data-enabled_next = abap_true.
 ls_data-status2 = CL_WD_PHASE=E_STATUS-WARNING.
 ls_data-status3 = CL_WD_PHASE=E_STATUS-WARNING.
 ls_data-selectedphase = 'PHASE1'.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

As we can see,we selected the first phase: ls_data-selectedphase = ‘PHASE1’and we set the Phase2 and Phase3 with the Warning status ls_data-status2 = cl_wd_phase) e_status-warning. ls_data-status3 = cl_wd_phase) e_status-warning.

Runtime

When the user presses the button, the Framework triggers the event handler method onactionnext (Listing).

The onactionnext event handler method

 METHOD onactionnext.
 DATA lr_node TYPE REF TO if_wd_context_node.
 DATA ls_data TYPE if_v_view=element_dynamic.
 DATA lv_phase TYPE string.
 lr_node = wd_context->get_child_node('DYNAMIC').
 lr_node-get_attribute
(EXPORTING name ='SELECTEDPHASE'IMPORTING value = lv_phase).
 CASE lv_phase.
 WHEN 'PHASE1'.
 ls_data-selected phase ='PHASE2'.
 ls_data-enabled_next = abap_true.
 ls_data-status2 = cl_wd_phase=e_status-completed.
 ls_data-status3 = cl_wd_phase=e_status-warning.
 wd_this-fire_op_to_v_phase2_plg( ).
 WHEN 'PHASE2'.
 ls_data-selectedphase = 'PHASE3'.
 ls_data-enabled_next = abap_false.
 ls_data-status2 = cl_wd_phase=e_status-completed.
 ls_data-status3 = cl_wd_phase=e_status-completed.
 wd_this-fire_op_to_v_phase3_plg( ).
 WHEN OTHERS.
 ls_data-enabled_next = abap_false.
 ENDCASE.
 lr_node-set_static_attributes(ls_data).
 ENDMETHOD.

As we can see, we make active the Phase2 ls_data-selectedphase ¼ ‘PHASE2’ we set the Phase2 with completed status and Phase3 with warning status ls_data-status2 cl_wd_phase )
e_status-completed.ls_data-status3 = cl_wd_phase)e_status-warning.

For the next press of the NEXT button,we set the Phase2 and Phase3 with completed status

ls_data-status2 cl_wd_phase)e_status-completed.
ls_data-status3 cl_wd_phase)e_status-completed.we make active the last Phase, ls_data-selectedphase = ‘PHASE3’.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_PHASE_INDICATOR

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a PhaseIndicator UI element

Dynamic programming

For the PhaseIndicator UI element,we have,as aggregation, the Phase element. It has the CL_WD_PHASE runtime class.
The implementation of a dynamic PhaseIndicator UI element with two Phases contains the following statements (Listing ):

Dynamic programming of a PhaseIndicator UI element

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_phaseindicator TYPE REF TO cl_wd_phase_indicator.
 DATA lr_phase1 TYPE REF TO cl_wd_phase.
 DATA lr_phase2 TYPE REF TO cl_wd_phase.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_phaseindicator = cl_wd_phase_indicator=>new_phase_indicator(
 id = 'PI_PHASEINDICATOR'
 bind_selected_phase ='DYNAMIC.SELECTEDPHASE'
 irst_visible_phase ='PHASE1'
 background_design = cl_wd_phase_indicator=>e_background_designtransparent
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_phaseindicator).
 lr_container->add_child(lr_phaseindicator).
 lr_phase1 = cl_wd_phase=>new_phase(
 id ='PHASE1'
 description ='PHASE 1'
 status = cl_wd_phase=>e_status-completed
 ).
 lr_phaseindicator->add_phase(the_phase = lr_phase1).
 lr_phase2 = cl_wd_phase=>new_phase(
 ld ='PHASE2'
 description ='PHASE 2'
 bind_status ='DYNAMIC.STATUS2'
 ).
 lr_phaseindicator->add_phase(the_phase = lr_phase2).
 ENDIF.
 ENDMETHOD.

Tree - Sequential Implementation

With this UI element,we can visualise the hierarchy defined in the context. For this UI element,we can use:

  • A sequential implementation with a non-recursive node in case the number of levels can be specified at design time
  • A recursive implementation with a recursive node in case the number of levels is not known at design time

WD component

In this case(sequential implementation,we don’t need a recursive node. A context node TREE is created in the context node of the view controller. It has the cardinality 1...1 and is Singleton.Under this context node,we create another context node TREE_NODE with two attributes. Under this context node,we create another context node TREE_LEAF with an attribute (Fig.)

Context structure

The attributes STUDENTNAME, VALUE and STUDENTINFO are of STRING type.The context node TREE_LEAF is not Singleton,because we need to create an instance of this node for each element of the TREE_NODE context node.In the STUDENTNAME attribute, we hold the name of each student; for each student we have proper information held in the attribute STUDENTINFO. In a Tree UI element, we can insert Node Types of type TreeItemType and TreeNodeType,to specify which subnodes and which context attributes are going to be displayed.

Inserting Node Type

View layout

Binding of the Context to the Tree elements

The context node TREE_NODE is populated via the supply function method.

TREE_NODE context node

 METHOD supply_tree_node.
 DATA:
 ls_studentTYPE 
if_v_view=element_tree_node,lt_student LIKE TABLE OF ls_student.
 ls_student-studentname = 'Ionescu Ana Maria'.
 ls_student-value = 'A'.
 APPEND ls_student TO lt_student.
 ls_student-studentname = 'Marinescu Loredana'.
 ls_student-value = 'B'.
 APPEND ls_student TO lt_student.
 ls_student-studentname = 'Marton Luminita'.
 ls_student-value = 'C'.
 APPEND ls_student TO lt_student.
 node-bind_table(lt_student ).
 ENDMETHOD.

The values for the child node TREE_LEAF are set in the same way via a supply function method.

Populating the attributes of the TREE_LEAF context node

 METHOD supply_tree_leaf.
 DATA:
 ls_studentTYPE if_v_view=>
 element_tree_leaf,lt_student LIKE TABLE OF ls_student.
 DATA: lv_value TYPE string.
 parent_element->get_attribute
(EXPORTING name = 'VALUE'IMPORTING value = lv_value ).
 CASE lv_value.
 WHEN 'A'.
 ls_student-student info ='Article - YES'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo = 'Exam - 5'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo = 'Academic year -II'.
 APPEND ls_student TO lt_student.
 WHEN 'B'.
 ls_student-studentinfo ='Article - NO'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Academic year -I'.
 APPEND ls_student TO lt_student.
 WHEN OTHERS.
 ls_student-studentinfo ='Article - YES'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Exam - 3'.
 APPEND ls_student TO lt_student.
 ls_student-studentinfo ='Academic year -IV'.
 APPEND ls_student TO lt_student.
 ENDCASE.
 node-bind_table(lt_student).
 ENDMETHOD.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_TREE

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name,with the proper types,in case of dynamic programming of a Tree UI element.

Dynamic programming

For the Tree UI element, we have, as aggregation, the Node Types: TreeItem-Type and TreeNodeType. The TreeItemType element has the CL_WD_TREE_ ITEM_TYPE runtime class and the TreeNodeType element has the CL_WD_TREE_NODE_TYPE runtime class.

The implementation of a dynamic Tree UI element with two node types (Tree- NodeType and TreeItemType)contains the following statements:

Dynamic programming

 METHOD wddomodifyview.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_tree TYPE REF TO cl_wd_tree.
 DATA lr_treenode TYPE REF TO cl_wd_tree_node_type.
 DATA lr_treeitem TYPE REF TO cl_wd_tree_item_type.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_tree = cl_wd_tree=>new_tree(
 id = 'TRE_SEQUENTIAL'
 bind_data_source = 'TREE'
 title = 'Student info'
 default_node_icon_source = '~Icon/CheckedOk'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_tree).
 lr_container->add_child(lr_tree).
 lr_treenode = cl_wd_tree_node_type=>new_tree_node_type(
 id ='TREE_NT'
 bind_data_source ='TREE.TREE_NODE'
 bind_text ='TREE.TREE_NODE.STUDENTNAME'
 ).
 lr_treeitem = cl_wd_tree_item_type=>new_tree_item_type(
 id ='TREE_IT'
 bind_data_source ='TREE.TREE_NODE.TREE_LEAF'
 bind_text ='TREE.TREE_NODE.TREE_LEAF.STUDENTINFO'
 ).
 lr_tree->add_node_type(index = 1
 the_node_type = lr_treenode).
 lr_tree->add_node_type(index = 2
 the_node_type = lr_treeitem).
 ENDIF.
 ENDMETHOD.

DateNavigator

This UI element offers the possibilities to display and navigate in a calendar and to enter dates, by choosing a year, a month,a day or a range of dates,from the showed calendar.

Hereunder,we present a table with some of the DataNavigator properties that can be bound, and the attribute type in case the property is bindable.

Some of the DataNavigator UI element properties

We create a WD Component named Y_UI_DATENAVIGATOR. In the context view,we create three attributes: MONTH, WEEK and DAY of STRING type,and two context nodes:

  • LEGEND,Cardinality 0. . .n,
    supply function named SUPPLY_LEGEND,attributes:
    CATEGORY of WDY_MD_DATE_MARKING_CATEGORY type and TEXT of STRING type
  • MARKING,Cardinality 0...n,supply function named SUPPLY_MARKING, attributes: CATEGORY of WDY_MD_DATE_MARKING_CATEGORY type and DATE of D type.

In the view layout,we insert a DateNavigator UI element with a DateNavigator- Legend and DateNavigatorMarking. By using the DateNavigatorLegend element,we can add a legend for the DateNavigator, and with the DateNavigator- Marking element,we can highlight entries of a specific category within the Date- Navigator UI element.

Context view and DateNavigatorLegend, DateNavigatorMarking properties

The most important properties of the DateNavigatorLegend element are:

  • “Category”,which allows us to create the legend categories (in format one,two,three and four).It shall be bound to a context attribute that stores these categories.
  • “Text”, which stores the texts, describing each category.
  • “DataSource”,which shall be bound to a context node,which stores the categories and the texts of the legend entries. The most important properties of the DateNavigatorMarking element are:
  • “Category”,which shall be bound to a context attribute that stores the category of the highlighted data.
  • “DataSource”,which shall be bound to a context node which stores the categories,data and tooltip of the highlighted data.
  • “Tooltip” is not necessarily bindable. In our case,we have not created an attribute for the tooltip,because we don’t want to display a quick info text when the user passes the mouse pointer over the highlighted data of the Date- Navigator UI element.
  • “Data” shall be bound to a context attribute that stores the date of the highlighted data.

View layout

The DateNavigator UI element has many properties and events. In our case,we have changed the properties:

 

In this way,we have chosen Sunday as the first day of the week in our calendar.

In this way,we show 3 months in our calendar.

We have chosen from the list the range option,because we want to offer the possibility to select the range of dates.

We have set the starting date of our calendar. To be able to show,in the TextView UI elements,the week,the day or the month that the end-user selects in our calendar,we have used the events:onDaySelect,on Month Select and on Week Select.

Events of the DataNavigator UI element

First of all,we have to populate our nodes with values. The Listing shows the SUPPLY_LEGEND supply function method.

The SUPPLY_LEGEND supply function method

 METHOD supply_legend.
 DATA: ls_legend TYPE wd_this-element_legend,lt_legend LIKE TABLE OF ls_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-one.
 ls_legend-text = 'Doors open day'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=>e_category-two.
 ls_legend-text = 'Operating teams trip'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=>e_category-three.
 ls_legend-text = 'Happy hour'.
 INSERT ls_legend INTO TABLE lt_legend.
 node-bind_table( lt_legend ).
 ENDMETHOD.

We create three legend categories(one, two and three),with the texts:“Doors open day” for the first category, “Operating teams trip”for the second category and “Happy hour” for the third category. The Listing shows the SUPPLY_MARKING supply function method required to populate with values the MARKING node.

The SUPPLY_MARKING supply function method

 METHOD supply_legend.
 DATA: ls_legend TYPE wd_this-element_legend,lt_legend LIKE TABLE OF ls_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-one.
 ls_legend-text = 'Doors open day'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-two.
 ls_legend-text = 'Operating teams trip'.
 APPEND ls_legend TO lt_legend.
 ls_legend-category = cl_wd_date_nav_legend=e_category-three.
 ls_legend-text = 'Happy hour'.
 INSERT ls_legend INTO TABLE lt_legend.
 node-bind_table( lt_legend ).
 ENDMETHOD.

In this way we mark (highlight),for the first category,the day 11.08.2009,for the second category,the day 21.08.2009,and for the third category,the day 24.08.2009. When the user selects a day in our calendar,the Framework triggers the event handler method onactionon_day_select.

The onactionon_day_select event handler method

As import parameter, for our event handler method, we have the parameter named DAY of D type that holds the selected day. We pass this value in our DAY attribute created in the context view. When the user selects a Week in our calendar, the Framework triggers the event handler method onactionon_week_select.

The onactionon_week_select event handler method

As import parameter,for our event handler method,we have the parameters: WEEK of I type that holds the selected week and YEAR of I type that holds the corresponding year of the selected week. We pass these values in our WEEK attribute created in the context view. When the user selects a Month in our calendar,the Framework triggers the event handler method onactionon_month_select.

The onactionon_month_select event handler method, As import parameters,for our event handler method,we have: MONTH of I type that holds the selected month and YEAR of I type that holds the corresponding of the selected month. We pass these values in our MONTH attribute created in context view.

Runtime

Dynamic Programming

RUNTIME CLASS: CL_WD_DATE_NAVIGATOR

Hereunder,we present a table showing the correspondence between the view designer name and the runtime name, with the proper types,in case of dynamic programming of a DateNavigation UI element.

Dynamic programming

The implementation of a dynamic DateNavigator UI element with elements: DateNavigatorLegent and DateNavigatorMarking, contains the following statements:

Dynamic programming of a DataNavigator UI element

 METHOD wddomodifyview.
 DATA lr_date_navigator TYPE REF TO cl_wd_date_navigator.
 DATA lr_flow_data TYPE REF TO cl_wd_flow_data.
 DATA lr_container TYPE REF TO cl_wd_uielement_container.
 DATA lr_datenav_legend TYPE REF TO cl_wd_date_nav_legend.
 DATA lr_datenav_marking TYPE REF TO cl_wd_date_nav_marking.
 IF first_time EQ abap_true.
 lr_container ?= view->get_element('ROOTUIELEMENTCONTAINER').
 lr_date_navigator = cl_wd_date_navigator=>new_date_navigator(
 id ='DATENAVIGATOR'
 first_day_of_week = cl_wd_date_navigator=>e_first_day_of_week-sunday
 months_per_column = 1
 months_per_row = 3
 selection_mode = cl_wd_date_navigator=>e_selection_mode-range
 starts_with ='20090801'
 on_day_select ='ON_DAY_SELECT'
 on_month_select ='ON_MONTH_SELECT'
 on_week_select ='ON_WEEK_SELECT'
 ).
 lr_flow_data = cl_wd_flow_data=>new_flow_data(element =
 lr_date_navigator).
 lr_container->add_child(lr_date_navigator).
 lr_datenav_legend = cl_wd_date_nav_legend=>new_date_nav_legend(
 id ='DATENAVIGATORLEGEND'
 bind_category ='LEGEND.CATEGORY'
 bind_data_source ='LEGEND'
 bind_text ='LEGEND.TEXT'
 ).
 lr_date_navigator->set_legend(the_legend = lr_datenav_legend).
 lr_datenav_marking = cl_wd_date_nav_marking=>new_date_nav_marking(
 id = 'DATENAVIGATORMARKING'
 bind_category = MARKING.CATEGORY'
 bind_data_source ='MARKING'
 bind_date ='MARKING.DATE'
 ).
 lr_date_navigator->set_marking(the_marking=lr_datenav_marking) 
 ENDIF.
 ENDMETHOD.

Searches relevant to you
Top