STEP BY STEP SAP BI

User Interface Elements (UI elements) Static and Dynamic Programming-part-3

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.

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

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

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)

Context structure

V_STEP1 view layout

V_STEP2 view layout

V_STEP3 view layout

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

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

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

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

Some of the PhaseIndicator UI element properties

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

Inserting Phase into a PhaseIndicator

Context structure

The V_VIEW layout

Window structure

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.

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.

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

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

Context structure

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

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.

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.

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.

STEP BY STEP SAP BI

Pages

Saturday, September 22, 2012

No comments:

Post a Comment